Is it no code or no programmer that’s the goal. The latter seems reasonable if you’re software product customer that would like to trim out the person between you and the product that seems to be slow only to misunderstand what’s needed.
E.g. if you could get the end product with Less waiting and miscommunication. I can see that being a sales pitch that resonates
That seems to be the gist of it. SaaS seems to tackle this specific issue by trying to move everything away from the customers in the first place. Don't need sysadmins or software devs(here) if they're in the cloud(over there).
Their pricing model is often advantageous to smaller companies aswell; only paying for what you use, even if that price is ridiculous per unit sold, it still often beats hiring dedicated staff. This effect lessens over time as company grows.
Intelligent subject-matter experts who are non-programmers can build 80 to 90% of their business info capture and reporting requirements inside the walled garden of their chosen platform.
Programmers are called in temporarily to complete the final 10 to 20% of the LowCode app, and integrate with external services.
It's been happening since Excel, through to Wordpress and nowadays splintered into 100's of directions and platforms from Wix to Podio to Notion.so
That is because we've built tools that are good enough for most use cases, and the cases don't actually differ all that much. For every new case however, new software has to be made. It isn't getting any easier, there is just more of it now.
The problem is that a "problem" is essentially a fractal; it needs a defined accuracy and scope to be solvable. Differing scopes and accuracies again require overhauls of software that would otherwise be acceptable for the same task.
I'm compelled to invoke the "Ninety-Ninety" rule when I hear about solutions like that, although I'm sure it works sometimes, in my experience it usually turns out more like this.
The first 90% of the work takes 90% of the time, and the remaining 10% of the work takes the other 90% of the time!
Yes it is, but if you're doing the first 90% properly you have a much better shot at mitigating the difficulty of the last 10%.
I think there's some vague point in any project where it goes from being 'easy' to 'hard' to add new stuff. Basically the only factor that matters for productivity is how long you can delay that point. If you just do the first 90% as quickly and cheaply as possible, you're just resigning yourself to hitting that point as early as possible.
I think this is best explained without exaggeration by the famous Design-Stamina Hypothesis[1], which states the notion that time spent on Design is something which you can trade away to improve development speed, is reliably false in the long-term (even if it seems to be working in the near term.)
The graphic also suggests that there is an inflection point, as you suggest, before where time spent on design really is just slowing you down in the beginning of your project, but also that the costs of waiting too long to switch modes (from doing no design, to doing good design) after you have crossed that line, are substantial and compounding; the longer you wait, the more your lack of good design costs.
And of course, not pictured, is "bad design" which can be even worse than no design. Trying to find that inflection point and put it on your development schedule in advance is also a bit like trying to catch a falling knife (not likely to succeed.)
But to hear it explained that way, it just seems like wishful thinking based on a circular reasoning, that invites an invocation of the rule... "We spend too much on our developer staff, so in the future we have adopted a strategy where we will avoid most of the things that we need a team of developers for, so that our developers have less work to do, so that we can have fewer expensive devs (of which we know we cannot dispose entirely, [because we are subconsciously aware without them, there is no innovation to speak of at all.])"
The problem that "Low Code" or "No Code" addresses is a real one, where devs like myself, (surely not myself, but someone more junior...) confuse poorly architected slipshod solutions for innovative ones.
If we could reliably keep our code as simple as it ought to be, the market for tools like this would probably not be as large as it is.
Kinda, it sounds very similar to the 80/20 rule. The 80/20 rule says 80% of the solution takes 20% of the time. So it's not quite the same.
In other words, the 80/20 rule says the last 20% takes 4x as long as the first 80%. In comparison, the above quote says the last 10% takes just as long as the first 90%. So slightly different.
Both this "90-90" and "80-20" indicate that the devil is in the detail. e.g. You can expect surprises as you're almost done, there's an inherent complexity to the solution, etc.
But saying "the first 90% takes 90% of the time" blatantly ignores these anticipatable unknowns; so it's a much more tongue-in-cheek thing to say.
In my experience, "Low Code" is almost always weasel-wording. It's used to describe products that try to be "No Code", but fall short. It's a way of making excuses for everything you can't do, because you can get a "real programmer" to come in and paper over the cracks. Actually writing this code is rarely a pleasant experience, and the learning curve is a cliff that goes straight from "flowchart" to "writing React" (or worse).
As other replies have pointed out, the really successful tools are like Excel: They have a real programming language at the heart of them, and they don't try to hide it away.
Disclaimer: I founded and run something you could call a "Low-Code web environment" (https://anvil.works) - but I prefer "Visual Basic for the Web" (or "Web Apps With Nothing but Python"). We built it around the idea that writing code is inevitable - indeed, it's the best way to tell a computer what to do. So don't try to hide it - make it a first-class experience!
About 2/3 of software cost is typically maintenance, not original creation. If some RAD-ish tool makes maintenance more difficult, saving time up front doesn't mean a lot, other than maybe as practical prototyping. Maintenance costs include getting new staff familiar with a tool, and the turnover rate is typically around 4 years for developers. Self-taught programmers tend to produce spaghetti systems, in my experience. My first programs were spaghetti, I must say. I was an IT puppy. I short, consider the medium and long-term costs of RAD/code-free tools.
While I agree with the author, it's only true when speaking of software that requires custom logic.
For instance, "no-code" website creation offering has done wonders in replacing the "install wordpress on a very crappy cheap host and let it rot with vulnerable plugins" paradigm.
Is that very different from the websites of the 90s? I distinctly remember creating a somewhat-dynamic site in FrontPage, then rendering it into static HTML and FTPing it to the webserver.
Perhaps this was an impedance mismatch: "web requires coding" - it mostly doesn't, most people would be okay with a better HTML editor, and providing that via WP was a historical quirk.
Those would be examples of static sites, which are "read only" to most users. Wix, Squarespace etc can handle form submissions and online payments of course. And with third party solutions like Intercom and Optimizely, things like customer support chat and A/B testing can be done with pretty much no code.
Web hosting companies in the old days often provided a collection of CGI scripts that users could invoke from their HTML pages, things like counters, e-mail form handlers, guestbooks and other popular functionality.
Having made a no code tool myself at yazz.com I definitely agree with many parts of this article. For prototypes or very simple one screen crud apps no code can be the right fit
Sure you can replace 4-5 lines of python with some box-based UI rule system, but anybody who’s not first week out of a 2 week coding boot-camp knows that the devil is in the detail. What if instead of “display error” it’s “try again if it’s a mail server error up to a maximum of 4 tries then email the administrator and save debugging info”
Then what about a loop? Have you ever tried to debug a loop in a UI programming environment? What about a complex loop with custom data types and no ability to see a stack trace or variable list? You gotta put print dialogs and system exits all over the place, and oh, the print dialog only prints a small string? Now you gotta do 1 variable at a time, 200 times to debug. Now I’m showing this to the “non-coder” who’s thinking “this is a giant headache” - and you know what??? HE IS RIGHT, because we have both been forced to use this crappy, blunt tool. Wasn’t this supposed to make things EASIER? Now the business guy AND the programmer are tied up trying to shoehorn what would otherwise be trivial for the programmer into this weeks novelty rinky-dink “no code” tool
Ui drag and drop replacements only work for trivial examples, or they become a giant unmaintainable spaghetti diagram that’s so complex you can’t even follow the lines, let alone understand program control flow.
The fundamental problem with existing software is composability. Us geeks have it at the command line, but regular users can’t pipe their brower through grep them to their printer,
Users are stuck with the fixed options available at software design time, if we could standardise a composable interface on all software (I don’t think “bytes” is the right abstraction for this, it’s too low level) then users can start dynamically composing their own solutions, which will take a decent shift in thinking for most people - but a generational cycle will fix it if young kids grow up taking composability for granted
This delusion is especially visible in the DevOps space. For some reason we have decided as an industry that instead of writing some code in whatever 'real' language we will base operational work on YAML with ad-hoc templating and stringly-typed programming constructs.
The main culprits are Ansible/Salt and all the string-templating based tools for Kubernetes (Helm/Kustomize/...).
Especially with tools like Helm I believe we reached peak insanity levels. Instead of using a general purpose or configuration-specific (like Jsonnet/Cue/Dhall) programming language to build and then emit in-memory objects to YAML manifests, the industry is using YAML to define templated YAML and then parametrize this templating with even more YAML.
Now we just write complex declarative configuration with no debugging facilities, a non-existent type system, inversion of control that usually ends up working against us and no way to interact with external data apart from stringing everything together with fragile shell scripts. But hey, there's no need to write a single line of Go/Python/Java/Ruby!
Thank god trends like Pulumi and the new AWS sdk is emerging.
General purpose programing languages are getting more expressive by the day, why do we use data serialization languages instead for configs? it doesn't make any sense.
The main problem is that, in my experience, the majority of DevOps teams are Ops teams that have been renamed and refocused towards automation.
These are people that by and large don't want to code, not saying that they can't or won't.
To be fair this has been in Windows shops, where scripting has only recently (last 5-10 years) taken off, so you've got a lot of windows admins that the closest they've been to code is Batch scripting with a bit of Powershell. This is a big change for them
As it happens i read about pulumi recently and I've put it on mt list of todo things, but I can't see that I'll be able to sell it to our team and our team is blessed (cursed?) with three former developers
> The main problem is that, in my experience, the majority of DevOps teams are Ops teams that have been renamed and refocused towards automation.
I'm on a relatively new team kind of like that (it's not a former Ops team but most of the team was pulled from Ops/DBA/analysis teams, and fits the description, and it's not a really a DevOps but more of a Dev+Ops team) and the general reaction of the team to being introduceed to the AWS CDK has been “we need to move to that as soon as we can”, even from people who very vocally never wanted to be programmers. And that's with, in many cases, a couple months experience with both programming and YAML IAC in the form of CloudFormation.
> These are people that by and large don't want to code
I disagree. That's the stereotype that tool builders have of such people. Good ops people have always loved coding, or we wouldn't be living on the mountains of Bash scripts also known as "Linux distributions".
(Besides, people who don't like to code won't like writing tons of declarative markup either. So there is little point in the current approach either way.)
It might be a stereotype but it's also my experience, which granted is limited and Windows based, which as I pointed out in the previous comment hasn't been really onboard with the scripting experience until relatively recently
As to the declarative markup, for instance Azure Devops still doesn't have feature parity between YAML pipelines and classic pipelines, so while you could well be right about the same resistance to yaml, it's not, necessarily an issue yet.
Most devops tools are built on Linux for Linux, then ported to Windows later as an afterthought, so I don’t think platforms are much of a factor. It’s a defect in the production pipeline somewhere, something like feedback from potential users not reaching developers until it’s too late. It doesn’t help that, in some cases, vendors just impose what is going to happen, and the community is simply forced to put up with it.
I still have my reservations against Pulumi in particular, though.
I've only really skimmed their documentation, but the idea that calling 'new' against a VM class instantiates a VM in production seems to be to magical for my taste, and might be an indication that it's yet another product that targets the happy path more than what we tend to experience in production: failures.
> General purpose programing languages are getting more expressive by the day
You know, once upon a time, we understood that declarative approaches to software engineering were superior to imperative approaches, when declarative approaches are feasible. Declarative approaches are much safer and easier to test, at a cost of only being able to express what the tool accepting the declarative approach can understand. Imperative approaches are strictly worse for any problem set where a declarative approach solves the problem within performance requirements. The additional expressiveness of languages like Pulumi is the last thing I want.
YAML is a horrible language for declarative system configuration because a) any sufficiently complex system will require you to generate your declarative codebase in the name of maintainability, b) generating code for any language where whitespace is significant will lead you to an early death, and c) stringly-typed languages are fundamentally unmaintainable at sufficient scale. But this is not an indictment of a declarative approach! It is an indictment of YAML.
> Configuration is code not data.
Data > code. Data does not need to be debugged. The best code you can have is deleted code - deleted code does not need to be maintained, updated, or patched. Code is a necessary evil we write in order to build operable systems, not a virtue in and of itself.
There are declarative general purpose programing languages.
That data you are talking about does need to be debugged, like Helm charts and pipeline definitions. Sure data is better, but config is code, not data.
Generators need to be debugged, not data. It's very easy to test a generator - a few unit tests checking whether, for a given input, the generator produced the expected output, and you're set. Data sometimes needs to be cleaned, but there's no such thing as a bug in data.
Whether the generated declarative output produces the expected behavior on the part of the tool interpreting the declarative output is part of the tool's contract, not the generator or the declarative output. If you need to check the tool's behavior then either a) you wrote the tool or b) you're writing an acceptance test for the tool, which is an entirely different endeavor.
No, Helm uses charts (data) to generate object definitions (in YAML). Helm is the generator.
There's nothing that prevents you from writing a unit test that runs `helm template` directly to check whether a given chart with given values will produce a given set of YAML files.
Config is both. Config variables are data. The code that accesses and uses those variables is...well...code. they should be kept separate. Like any other code and data. Config isn't a separate special entity, it's just another part of the program. The data part should be represented as such and the code part should be code. Trying to combine them and create a special 'config' language is mistake.
That's a bit of a no-true-scotsman there. If the problem is just the markup of choice, we should see an alternative markup emerging any time now. If we see imperative-focused tools instead, maybe it's not just about the markup.
We do see alternative "markups", if you want to call them that, emerging that solve the generative issues - the two that come to mind are Dhall and CUE. They bring forth JSON to help them interoperate and be relevant in a world that predominately expects JSON/YAML, but they can also be read directly.
I think "declarative" is a bit of a red herring here. Deterministic/reproducible/pure is a more appropriate distinction: configuration languages like JSON/YAML/XML/s-expressions/etc. are trivially deterministic, but not very expressive, leading to boilerplate, repetition, external pre/post-processing scripts, etc.
Allowing computation can alleviate some of those problems, whether it's done "declaratively" (e.g. prolog-like, as in cue) or not (e.g. like idealised algol with memory cells).
The main reason to avoid jumping to something like Python isn't that it's "not declarative"; it's that Python is impure, and hence may give different results on each run (depending on external state, random number generators, etc.). Python can also perform arbitrary external effects, like deleting files, which is another manifestation of impurity that we'd generally like to avoid in config.
tl;dr The problem isn't the style of computation, it's the available primitives. Don't add non-deterministic or externally-visible effects to the language, and it wouldn't really matter to me whether it's "declarative" or not.
I use Lua for configuration files. It's easy to restrict what you can do in Lua (I load configuration data into its own global state with nothing it can reference but itself). Plus, I can define local data to help ease the configuration:
When I reference the configuration state, templates[1].output will be "/www/site/htdocs/index.html". And if the base directory changes, I only have to change it in one location, and not three.
> Thank god trends like Pulumi and the new AWS sdk is emerging.
The more things change, the more they stay the same.
The pendulum is swinging back towards scripting languages. But give it a few years, and we'll be railing against scripting languages for not being idempotent enough, and moving back to the latest version of YAML and XML (perhaps we'll go with TOML this time) with custom interpreters.
We have seen this half a dozen times already, between turing complete DSLs in ruby, to plain bash, perl, and python scripts. The other side are the DSLs written using YAML, JSON, and XML (and every other config language written in history).
Probably referring to the CDK (Cloud Development Kit), a newish SDK for developing Cloudformation infrastructure-as-code in general-purpose programming languages.
To play devils advocate, isn't the idea with Ansible at least that it's idempotent. The YAML should describe the final state and should be concerned with branching or lower level features like that.
(It's the same with SQL, you describe what you want back rather than how its achieved. A declarative approach works fairly well there.)
Emacs is configured using Lisp. Because of that it is amazingly configurable.
XMonad uses Haskell, which gives types to avoid lots of error cases.
The thing is providing an actually programming language doesn't remove anything specially if the same config can be written as cleanly.
And you would avoid "YAML templates for creating YAML", when you actually need to process some data (even if it's just for pre/suffix creation in names). Secrets retrieval is another thing that you also need to do and template.
Also, YAML is a terrible to parse language, with can give out weird error cases. Other languages compilers/interpreters are more mature.
And ofc, if you provide SDKs for your IaC tool, you should be able to use the language that your developers are more familiar with. Taking advantage of the good practices their are used to. Don't limit with "declarative languages". Use a programing language that make more sense, and leave data languages for data.
> What would be the benefit of adding a declaritive language into the mix over YAML?
The capability to readily define, store in libraries, and use reusable abstractions that apply within a configuration or across multiple individual configurations.
However, that final YAML-defined state is not guaranteed to define the entire functionality of the system. The typical counterexample is this: removing a 'create file' clause does not cause that file to be removed on subsequent runs, as the tool has no concept of ownership nor diffing against previous states. The emitted YAML does not represent the indended full state of the machine, just what actions to take to bring it from some unspecified historical state to an underspecified target state. There is no guarantee of consistency.
Thus, it is very easy to get in a situation where an Ansible playbook applied against two machines with slightly different production history will result in very different behaviour.
If you want real declarative configuration management, try Nix/NixOS.
> removing a 'create file' clause does not cause that file to be removed on subsequent runs, as the tool has no concept of ownership
Terraform on the other hand does have a concept of ownership, diff-ing, and applying changes. It takes some work as you now need to track state, but I've been very happy with Terraform.
While (most) actions in Ansible modules are idempotent the entire playbook is not. So how your system is going to look at the end of a run is highly dependent on the order of everything in your YAML files and the current state of the system. You can ensure a file exists in and part and remove the directory containing it in another, and you are non the wiser unless you run the playbook multiple times and pay attention to the changes.
What's needed is an internal data-structure that defines the state needed -- YAML declares the structure directly, but an alternative is to use either a DSL or even a general-purpose language to build that data-structure.
Of course, you could write code to generate your YAML, but the tooling is _not_ going to help you with that today.
Maven and Gradle are examples of each of these methods -- both build up an internal model of the build, but while Maven uses XML, Gradle uses a Groozy DSL.
> isn't the idea with Ansible at least that it's idempotent.
Sure, that's true with many of these, so what?
The problem isn't that the languages are declarative—functional code is declarative.
The problem is that they are extremely limited in their expressive capabilities, so that it is much more complex and error prone to describe the final state in them than it would be—even in a declarative style specifying the final configuration—in a more complete language than YAML (or, in many cases, a language essentially limited to JSON’s expressive capability even if it also supports a YAML serialization.)
> It's the same with SQL, you describe what you want back rather than how its achieved.
YAML would be an inadequate alternative for SQL’s role, too.
I'd argue somewhat that the approach works well for SQL. On a superficial level it allows you to hide the implementation details of your query execution. In practice not so much. Hence keywords like "explain" were invented and statements like "CREATE INDEX". And table partitioning. And hints. And myriad of other practices where the SQL abstraction "leaks" details from the layer below.
You can implement LUA in less lines of code than YAML, lua has been around longer, easier syntax, loads of support, proper community around it. Yet people still use YAML on hype alone, it's awful.
Well, I would have to disagree (but agree somewhat, as well :)). These insanity levels you describe, and I agree with you here, are actually pushed through projects by coders for coders.
Here in lie much of the ”devops” problem, imo, as coders seem to want to allow easy configuration management through “simple“ declarations, inventing almost a new language in the process.
Having worked for 20 years with systems/configuration management, mainly as a developer I can tell many coders have not. Not at scale, and not supporting 100s of different services simultaneously. Hence square wheels gets re-invented.
To be rid of all yaml templating and loosely coupled technical integrations you will have to treat config/service delivery/ci/cd/what-have-you as a business domain of it’s own, and develop it the same way.
I guess we agree, completely perhaps?! :)
I’ve been fortunate to have been able to work everything from small upstart to big corporate enterprises and to me this is more true now than ever.
As a developer I build my own version of a CMDB, I do not use crazy templating - I write an API, that leverages the CMDB and produces sane output.
It’s still configuration as code, just something that is easier to scale and adapt.
Guess I’m only disagreeing on whom to blame for this mess.
> Especially with tools like Helm I believe we reached peak insanity levels. Instead of using a general purpose or configuration-specific (like Jsonnet/Cue/Dhall) programming language to build and then emit in-memory objects to YAML manifests, the industry is using YAML to define templated YAML and then parametrize this templating with even more YAML.
As a big proponent of Dhall, I gotta say, probably the primary reason for that at this point is due to a lack of language bindings. Most tools in the Kubernetes ecosystem are written in Go. Currently, there is no official Go language binding for Dhall - one implementation[1] is pretty close, but the marshalling features need some work, and it's not the author's day job. The only way to get Dhall configuration into a Go program today is to either shell out and call the Haskell-based reference implementation directly or to script your Go binary such that the Haskell-based reference implementation translates the Dhall configuration to JSON and then feeds that into the Go program. Even that's not ideal - you end up maintaining your schema in Go code and in Dhall simultaneously.
I very much believe that Dhall will solve the stringly-typed insanity which you refer to, but the language is not quite there yet. While I'd love for some of the Kubernetes core developers to step up, I mean, I can understand people's unwillingness to adopt something that isn't 100% perfectly well-supported and handed to them on a silver platter.
There is a levels of indirection problem with that explanation.
Using Dhall to create the YML you will use isn't great, but it's quite possible today and is much better than using YAML to script a YAML generator that will read some more YAML to create the YAML you will use.
I agree, which is why I use Dhall at work. But the fact of the matter is that `kubectl apply -f config.dhall` isn't realistic yet, and there's a big segment of the market that's just not willing to accept anything but that.
The point of all this is that software configuration is never a simple declaration. It is always a mess of behaviors and derived values.
I am not sure I totally agree, but it at least correct enough to always break something. And adding abstraction layers just because you choose to use an underpowered notation at the bottom isn't a good practice.
Maybe because we've chosen such rigid, inexpressive and DSL-hostile programming languages for devops... I mean, Python, Go... ofc you'd rather write your DSL in YAML instead and forego any checking the language might provide since everything else would be too awkward. Something like a "statically typed Ruby" would probably shine here.
TL;DR: "your language sucks, my language would shine"
Language doesn't matter. What matters is the attitude of tool builders that everything should "simply" be described as data. When that turns out to be insufficient, as it inevitably does, hacks are introduced and sooner or later you end up with crippled and idiosyncratic pseudo-languages.
Exactly, the fix is also obvious but not quite happening just yet. Several languages now support internal domain specific languages. Several of those are strongly typed. And several of those can compile to native code and integrate with other stuff around them and also come typically with nice tool support in the form of syntax highlighting, auto complete, etc. Basically all the stuff that yaml sucks at can be fixed by having a richer language model than free form strings in free form objects and lists with no semantics whatsoever; no auto complete; and nothing but run time errors to tell you you copy pasted it wrong (because that's what happens when there is no tool support).
IMHO a big part of the problem is that the companies involved are actively incentivized to justify their existence by making things more complicated instead of less complicated. If things are too simple, nobody needs their consulting, training, support, etc. Worse most of these companies are competing for attention and typically only provide part of the solution instead of the whole solution. So there's a lot of money in cross integrating multiple complicated solutions from different companies. Indeed many of the companies involved are serial offenders when it comes to this. As soon as you get companies like Red Hat, Amazon, Oracle, etc. get interested in stuff, brace yourself for some convoluted vendor lockin. That's basically what happened to Kubernetes.
When it comes to languages, I'd love something that has a compiler and auto complete. I'd also like something that has a notion of internal domain specific languages. IMHO Typescript, Kotlin or Rust could work for this. The point of this would be leveraging a type system for static checks and code completion. That kind of rules out dynamic languages like javascript, python, or ruby (all of which have been used in devops in the past). They are nice but not nice enough.
However, typescript has enough static typing that you get some meaningful autocomplete. Also, it's already popular in the node.js world (i.e. lots of stuff available to integrate). Kotlin would also be able to fit in that world since there's a transpiler to javascript, it can utilize typescript type definitions and it integrates with node.js and npm. Rust would be a bit of an outlier here and probably a bit too much in terms of language complexity for the average yaml loving devops type with a mere few years of full stack experience. With Kotlin, the transition of gradle from groovy to Kotlin has been interesting. Groovy basically is a dynamically typed language and they've slowly been replacing it with the more strictly type Kotlin. That sort of stabilized with v5 and with v6 it got usable for a lot of projects and recent updates to Intellij have improved how it is able to support developers with e.g. code completion and other features. Something like that aimed at devops could work.
DSC or pure powershell has bunch of useful tools and a real programming language to use in between. Yaml like configuration can be achieved with nested HashTables that have almost equivalent readability without loosing any of the devlopment capabilities.
I'm reminded a bit of systemd. Whatever their problems, when things went south, it was usually fairly easy for someone who could code to walk through the init scripts involved and figure it out. The config files of systemd at first glance look quite simple and declarative, but if things don't work, one almost immediately slams into a wall of complexity.
Sometimes one doesn't "need" a coder because the system is such that it wouldn't do you any good anyway.
The idea isn't new. I first saw it as '4GLs', which were higher-level languages. Later we had rule engines and now AI.
Programmers never go away, though. Besides the need to write the customizations that the higher level languages miss, there is the need for disciplined thinking and testing. No matter how simple the tools become, the need for these remain.
I've been hearing about "no code" or "no programmer required" business solutions for over 20 years. Cynically, I encourage this thinking because my billable rate to untangle someone else's hot mess when urgent deadlines are looming goes up. Practically speaking, if the business problems being solved are complex you might be able to pull off a low-code solution but without knowledge and practice of the essential architectural patterns of software development a novice will paint themselves into a corner before they even know what they are doing, requiring an expert to come in an clean things up.
Around 1960 some people seriously claimed that within about 5 years there would be no more professional programmers because with this new language, everyone could write the software they need themselves, since it was so easy to use.
> Around 1960 some people seriously claimed that within about 5 years there would be no more professional programmers because with this new language, everyone could write the software they need themselves, since it was so easy to use.
Of course that prediction seems quaint now, but I posit that the prediction failed because they greatly underestimated the increase in demand of software as much as overestimated the expressiveness/productivity increase of COBOL (and later systems).
Heck, considering what a professional programmers job might have been like in the 50s, its not far fetched at all that such profession indeed has disappeared as modern programmers work at such a different level of abstraction
Yes, given that back then people were typically working in assembler (with frequently changing platforms, to boot) and writing relatively simple data processing applications, the claim is somewhat understandable.
But I think the main thing it failed to take into account is more how hard it is to translate business requirements into complete and unambiguous instructions.
The even bigger thing is how better tools and abstraction create more demand for code, as more can be done. The entire history of computers has seen software demand increase over time.
This reminds me of the Jevons paradox from economics. The story is that when steam engines became way more efficient, the demand for coal exploded. Even though each engine used much less energy, the total amount of energy consumed went through the roof.
There used to be an early ARPAnet mailing list called "INFO-COBOL@MC", that was actually for exchanging jokes and copyrighted Dave Barry articles (which was an officially prohibited abuse of the government sponsored ARPAnet). It was a great stealth name because nobody took COBOL seriously, and we would just laugh at people who posted COBOL questions.
Here are some old INFO-COBOL messages archived in the MIT-AI HUMOR directory:
To be fair, afaik (second hand account), when COBOL appeared it drove a bunch of non-expert programmers into the field, mostly domain-driven people. It really was a new age of programming. (which then-experts didn't really see in a positive light)
I think it's a little unfair to characterize COBOL as a failure in that regard. It tremendously increased the accessibility and use of programming and computing in general by way of consequence; it's been instrumental in allowing the programmer population to grow massively.
Granted, extraordinary superlative claims never materialize, but the intent, the vision is important ime. Especially in business settings.
Yes, in the 80's and 90's we called it CASE (Computer Aided Software Engineering). It was just as fascinating then and equally impractical now. Text turns out to be a great, compact way to convey ideas or instructions which is the heart of software development.
I don't think text is nearly as compact as people claim it to be.
I dabble in graphical programming languages from time-to-time, and one feature they all share is the editing environment for code makes entire categories of syntax error impossible; there is no way in the language's design to pass a string to a function that only accepts a number, for example, because the "blocks just don't fit together." It's a level of integration between the space of all possible arrangements of elements and the set of arrangements that constitute valid programs that I see text-based IDEs approach, but struggle to catch up with. And I suspect part of the challenge is that as a tool for describing programs, sequential text has too much dimensionality; the set of strings of sequential text is much, much larger than the set of valid programs, and it's easy to put text sequences together that aren't valid.
> there is no way in the language's design to pass a string to a function that only accepts a number, for example, because the "blocks just don't fit together."
Which is easily achieved by the first typed language that comes to hand, no?
Not without an IDE. It's still extremely possible (in all text-based languages I'm familiar with) to write the program with a typecheck error; the typechecker will gleefully catch it for you. At typecheck time. Often (depending on my toolchain) minutes after I've written the offending code and mounds of code depending on it.
It's possible, with many languages, to write IDEs that will make this hard, but I've yet to find one that makes it impossible. Certainly not in the same way that, for example, Scratch will simply refuse to let the offending blocks click together. I certainly don't advocate transitioning from text languages to Scratch, but I think there's meat on the bones of asking the question "Why, when I'm editing code in text-based languages, am I even allowed to reference a variable that is demonstrably the wrong type? What benefit is that gaining me?" Because I think the answer in a lot of cases is "No real benefit; editing, typechecking, and compilation have just historically been disjoint concerns with no feedback channel because writing those is hard."
I'm strong believer, even if that belief doesn't come up often, in structured editing[1] which sort of bridges the gap and makes writing invalid programs impossible, at least syntatically but I don't think adding type level checking is a big jump and I haven't kept up with research so that might already be there. Unfortunately I don't know any successful examples of that beyond research projects that I could point out. I remember hearing rumors that some of the LISP machines might have veered to that direction, but idk
Even more I don't believe in plain monospaced ASCII being the ultimate format for code. Luckily there I know one example that goes at least a bit further: Fortress[2], a language from Sun that had richer rendering format available (although the underlying form was still afaik textual). And of course APL is another example, albeit bit less easily approachable. Raku also has some cute tricks (of course it does) with unicode characters[3], but they are more really just tricks that radical revolution in design.
There are also lots of other interesting ideas on how to format and layout code in the research, just one random example is "code bubbles"/"debugger canvas"[4]
While I think all this and so much more has great potential, there is huge cultural entrenchment around simple text based programming that seems unlikely to be overcome any time soon. As for graphical programming, I think the common failure there is being often also heavily mouse-driven, while keyboard is really powerful input device.
[3] https://docs.raku.org/language/unicode_ascii for example "The atomic operators have U+269B ATOM SYMBOL incorporated into them. Their ASCII equivalents are ordinary subroutines, not operators". Obviously.
Re: "The atomic operators have U+269B ATOM SYMBOL incorporated into them. Their ASCII equivalents are ordinary subroutines, not operators". Obviously."
Except for the short-circuiting operators (such as || and &&) and the assignment operator, all operators in Raku are just subs with a special name. Adding your own operator to the language is as simple as adding a subroutine, e.g.:
sub prefix:<√>($value) { sqrt($value) }
say √9; # 3
Do you have examples of delivering actual production applications with a graphical programming language in less time than developing the same thing with a traditional text based language?
I don't, and the gap is (IMHO) wide between where the ones I've used are and where they'd need to be to compete with text input. The main hindrance is UI; keyboard is a relatively high-bandwidth input (in terms of bytes-per-second of usable signal), and most of the graphical languages I've seen are heavily mouse-centric with not enough accelerator keys to close the gap. I can generate a lot of incorrect code-per-second with a keyboard, but I can also generate a lot of code-per-second period.
I'm hoping someone can close the gap and bring us a graphical language with a robust keyboard interface to navigate through it and edit it, with the advantage of strong edit-time validation excluding invalid programs. If someone can close the gap, it'd be a hell of a thing to see.
FWIW I would argue that Sketch (and other applications like it, plus Unity, etc) are most accurately described as graphical programming languages -- highly domain-specific ones.
Conveying ideas and instructions is also at the heart of architecture. Digital representations are embedded at every stage of a contemporary building design and construction pipeline. 98% of those representations are something else than text.
I strongly believe software application design is fundamentally closer to architectural design than the kind of work done in a purely textual realm — say, writing a novel or a research paper. But it's a really hard nut to crack.
I hope CASE today is like AI and neural nets were in early 2000s — a bit of a laughing stock, "something people in the 1980s wasted a lot of time on but nowadays everyone knows it doesn't work."
I'm actually quite fond of some "no/low code" tools but there is a threshold of complexity beyond which if you use them then terrible abominations will result that are far more complex then the equivalent code and actually require more technical expertise then 'code' - so you end up with components that only a skilled developer can maintain in a platform that developers will hate.
I’ve dealt with a few of these too, and the point at which you should just give up and switch to python/bash/anything always comes sooner than you think.
The classic magnet for this: Microsoft Access. It's a fantastic force-multiplier until Dr. Jekyll turns into Mr. Hyde and begins grinding your business to a halt.
There are also a large number of projects - maybe majority? - that never reach that level of complexity; and the "no/low code" solution (like Excel, Access, etc.) enabled a non-engineer to solve a business problem without hiring any engineers.
That's where these kinds of systems shine, if done right; allow a "non-engineer" who has a logical mind / the engineering tao to create solutions without having to learn traditional development toolchain.
I read somewhere a quote that stuck with me: "No tool is ever going to free us from the burden of clarifying our ideas."
And that's how I view my job as a software developer: clarifying ideas.
Any "No Code" tool is still going to either force you to clarify your ideas, or have a large amount of assumptions. "Idea People" and "Business" don't like that, so they'll probably end up delegating the use of "No Code" tools to programmers of some sort.
There are plenty of tools that help us in clarifying our ideas though. Take mathematical notation for example. Or music notation. Or a CAD program.
All are examples of domain specific tools that allow the user to specify their intention in a non-ambiguous way. And they also allow the user to think about and experiment with the problem space.
I think what we need is something akin to this. The "business logic" that we are talking about here is to me a non-infinite domain. It should be possible to boil it down into a domain specific tool that is more helpful than a general purpose programming language.
Business domain vs. Math., that's an interesting comparison. The problem is that business domain is exact an "infinite domain", in comparing with Math. Or to say that the competitive nature of business is very much reliant on its ability to break its domain boundary. Again, not so much in the case of Math.
I will resonantly disagree here. Math is successful exactly because each time it had a rule that was problematic, people just extended it.
And the success of modern (20th+ century) Math is caused exactly by the fact that we got an inifinitely extensible language, so nobody has to ever break it again anymore.
I work at a large non-profit. I'm not a coder, but I'm IT literate, and know enough about database design to not do absolutely stupid things. I'm happy to document processes enjoy clarifying ideas.
We use Sharepoint. In many many respects Sharepoint is detestable garbage, but I have managed to create some really quite complex automated workflows which are saving people in the organisation a lot of time, using Sharepoint Designer (no coding). It's documented, fairly robust and I wouldn't have been able to write it in a conventional language.
I'd say you're at least some kind of coder. My point is that there will always be room in an organization for people like us, who aren't afraid to go down and use our tools to the fullest extent, to save "people in the organization" enormous amounts of time. These tools can be code or something else, but the point is clarifying ideas. The exact tool you use doesn't matter.
"No Code" is not an existential threat to developers, it's just another programming language.
Stateflow enables better communication with domain experts at automotive OEMs than any other formal or non formal specification language I know. So I'd count this as "plus No Code".
Part of it is "clarifying ideas". But I think there's another important part:
Clarifying processes
I'd wager that the vast majority of businesses have no idea how their internal processes actually operate, what steps they take, what steps are already automated, what steps are not automated but could be, and what steps don't seem like steps but are actually super-important parts of the overall process.
I'm not an expert in the domain, but a few employers ago I worked for a company that was heavily involved in Six Sigma. Yes, it was a management buzzword. In many cases it was probably being used wrong. Or was being applied in a manner orthogonal to the problem. Or...any number of other things.
But one thing we studied in our "off time" (the company was a focused membership organization - we had magazines, conferences, everything) was how to apply 6S to our own business (you'd think that would have been done from the beginning - you'd be wrong). One thing we looked into, and attempted to understand and apply, was business process mapping.
That is - everything (and more) that I noted above - in various forms of flow-charting and other process mapping diagram systems, mostly done by hand, as it was easier for multiple people to see the processes and reason about them. Once we had things relatively "tacked down", we would convert those over to an electronic form.
It was an interesting exercise, and we never completely finished it before I moved on (the company went belly up soon after I left, as I was the only SWE left - it wasn't a large business). But we did notice in the exercise some interesting things:
1. If your business process flowchart looks messy, and can't be "untangled" - there are problems with your process.
2. Similar to #1 - if the flowchart looks unbalanced, even after untangling, there may be issues with the process as a whole.
3. Process flow lines that cross should be avoided; usually this is just a result of how things are arranged, but if you re-arrange things and still find a lot of criss-crossing lines, and can't make them not cross - again, issues may be there.
4. Soft processes are real processes - and trips things up. These are things where you might do something "out of the loop" or talk to somebody about something - but it doesn't seem like a real part of the process - but if it weren't done - the whole thing would break. Usually, these kinds of things aren't uncovered until one or another party leaves, either permanently or while "on vacation". Sometimes, the issue doesn't appear until some automation is put in that leaves that soft-process out, or unintentionally goes around it - then it can stick out like a sore thumb. Identifying these processes - and they can be difficult to identify, as sometimes even the person doing it doesn't know they do it, as you talk to them about their role in the overall process. You have to watch them do it.
This last one - there's a story I once read, I'll condense it as best as possible:
A woman brings her car into the shop complaining that the vehicle isn't running well after driving it a while. She gets in it to go to work, and at first it's ok, but within a mile or so it doesn't run very well. She doesn't know what is wrong. The mechanic looks at it, starts it up, it seems like it runs well. He tries it in the morning, everything is ok. He calls the owner and she comes into the shop and gets her car, but returns the next day complaining that it is still running strange. The mechanic asks if he can take a ride with her, to show him the problem. She says sure, they get inside the car, and as he sits down in the passenger seat, he sees her pull out the choke and hang her purse on it. It turns out that her previous car had a special pull out "hook" for just that purpose, and she didn't know. After the mechanic explained the problem, she had no idea, but the problem wa...
I think this line in particular is a good TL;DR of the issues discussed in the linked article:
> The complexity of software is an essential property, not an accidental one. Hence descriptions of a software entity that abstract away its complexity often abstract away its essence.
I agree with the author in all points about the no-code movement and goals, but disagree with the larger points about software development and engineering in the business setting.
In particular, the attractiveness of no-code should not be that one does not have to have in-house software development, but that one has less technical debt and thus smaller technical interest payments. Businesses will always have problems with computers, because computers are rigid and unyielding, while businesspeople are soft and compromising.
It is all to easy to read the beginning few paragraphs as the sourest of grapes: The businessperson, having embraced fax, email, paperless, Web, and mobile, is nonetheless no closer to having embraced computer. The "traditional sense" of creating software is derided as "expensive, in short supply, and fundamentally [not quick at] produc[ing] things." But that is all explained neatly by market forces: Developers are expensive because competency is rare because understanding is low because computerizing is a painful commitment because operationalizing a business is equivalent to automating it away. Computers reveal the rent-seeking and capitalization simply by being themselves on their own.
BASIC was an attempt to allow people to write software
in what looked like English, and indeed it was extremely
successful (cf. Visual Basic).
The language designed to look like English was COBOL. BASIC looked nothing like English. The reason it became popular was because you could develop programs interactively - edit, run, load, and save programs - without ever leaving the system. It was still programming, though (as was COBOL).
Visual Basic was released many years later, and looked very different from the original BASIC.
I'm not really sure I'm seeing anything that isn't the logical continuation of the move from low-level languages to higher level languages, and from lots of bespoke software to frameworks and libraries.
A big pile of Zapier gunk might be brittle, but I think tools like it are a natural progression in a society where everything is dependent on computers. To me it's part of "Everyone should learn to code".
I've spent a long time trying to build "No Code" solutions. Probably 3 different products, 3 different companies. But once, I tried something different. I pushed back, instead I proposed we build a domain specific language using Ruby. I already had some trust with my boss... and he was pretty convinced it was going to fail, he had zero faith these smart (but non-technical) users could successfully use it. But he was willing to let me fail. So we tried it, and really surprisingly, they caught on very quickly, and they were producing complex content within a week.
"No Code" solutions are like asking your user to communicate using pictographs. It's possible, but language allows users to communicate in better detail faster. In school I learned how to write, I'm probably not anywhere close to writing a novel. I'm a terrible writer, but I can write an email. Frankly, that get's me pretty far.
That is really cool. How did you go about designing the language. Did you go for a full lexer and parser ? or it was more functional. Curious to understand how you built it.
Ruby's super power is it's meta programming ability. So they were really just writing Ruby. If you google, I think there's a bunch of tutorials out there for creating a DSL in Ruby... but I learned from a book called "Metaprogramming Ruby"
Thanks for the book recommendation, I am eager to read it.
I looked on Amazon but there are only used paperbacks and no Kindle edition. But I saw from the cover that it was a Pragmatic Press book, so looked for it there and they have a no-DRM ebook of the second edition - for a lot less money than the used copies on Amazon!
Did you do anything special presentation/interface-wise?
My impression is that a good part of it for many is not making them realize that they are "programming" until they've already accepted that they can do it, because otherwise they "know" that it is too difficult.
I actually wrote a plugin for sublime, which allowed them to write the script then directly upload to our service, it also had some code snippets in it so they could right click, then quickly add and modify what they needed while they were learning (this feature was not used as much though, watching them, they seemed to prefer looking at scripts that did something similar and just copy and pasting from it). But other than that, it was just sublime.
> because otherwise they "know" that it is too difficult.
This is something that frustrates me in general, and I'm sure others, too:
That there seems to be among a certain population of people a mindset that declares failure before they've even tried. Or, they try, but at the first hint of failure or trouble, they declare that they can't do it, and stop.
So what is different about those people who don't do this? Why do they instead take up new challenges, and when they fail, try again. When they run up against difficulty, they step back, think about their options, perhaps consult experts in the domain, and continue on?
And how do we get the former group to join the latter?
I know there isn't an easy answer to this, if there is one at all; I know I'm not the first to observe this issue either - it's likely something that has been observed and wondered upon for thousands of years.
...but nonetheless, it continues to be frustrating.
I think its a matter of motivation. They’re not sufficiently motivated to push through the boredom or frustration they feel at the start. That’s ok, most people don’t beed to learn it, but as I say in another comment here, I do believe that most people can learn if they have a problem that they could solve with programming that the want to solve badly enough.
Most people don’t care enough though and life’s too short to spend on something when other things are more important to you.
> That there seems to be among a certain population of people a mindset that declares failure before they've even tried. Or, they try, but at the first hint of failure or trouble, they declare that they can't do it, and stop.
You just described my three year old's eating habits.
In the 1970s, secretaries not only used Multics Emacs, they were trained to customize it in Emacs Lisp. Because they were only ever told they were "customizing" the editor, not programming it, they developed useful extensions -- in Lisp! -- without ever realizing that they were writing programs!
I second this. People can go very, very far with simple and sand boxed Domain Specific Languages that are targeted towards the core function.
There are so many commercial successes for this approach: CAD, MATLAB, Simulink, LabVIEW, Dymola, Excel (?)
The biggest issue with many of these tools is that they tend to be closed source, proprietary formats, onerous licensing terms, not easily extended and aren't easy to deploy into an automated production workflow.
Some are addressing this with an option to export a compiled binary, but many try to up sell you complete ecosystems (PLM) to keep you locked into their proprietary formats. This tends to frustrate devs.
if you just remember that all the classic unix-editors were used by secretaries/data input persons picked right from the typewriter, that's not surprising at all. What's surprising is that this insight was so fully eradicated by years of IBM/MS/Apple-marketing (except for the lone warehouses still running on IBM mainframes with terminal frontends)...
I’m a programmer with 15 years of professional experience and another 10 as a student and hobbyist before that. My brother is a carpenter by training who was never even the slightest bit interested in programming. Last year, he learned Pine script[1] because he wanted to customize stuff on TradingView.com. Sure, he doesn’t really understand all the details and sometimes asks me for help, but he is able to successfully get the results he wants. I think most people just need sufficient motivation and they’ll get it. I’ve always said that the reason most people don’t learn to program isn’t because they can’t, but because they don’t really have enough reason to put the time and effort in.
Learning a skill takes time and tenacity. Years ago, I tried to learn guitar, but gave up after a few months because progress was too slow for me. I was impatient and not motivated enough and therefore ultimately didn’t get anywhere. Two years ago, I decided I wanted to learn sleight of hand card “magic”. There was one flourish in particular that I just couldn’t do, but I kept trying anyway. Day after day, I couldn’t do it and then one day I realised I could. The only difference between that and guitar is that I kept at it and out the effort in.
Sure, some people are predisposed to certain things which is a bit of a shortcut (I definitely found programming easier to learn than card magic), but I believe that most people can learn most things, if they have sufficient motivation and put in the time and effort (I include finding a way that works for you as part if effort, just doing something repeatedly may not be enough on its own, as they say: “practice makes permanent; perfect practice makes perfect” — ie be careful of learning bad habits that may get in your way)
I’m personally not against visual programming and have had some good experiences with it, but the name “no code” in my opinion completely misses the point: its still code (and programming). The text was never the hardest part, so by eliminating that, you’re not really winning much. The hard part is the logic, calculations, data manipulation and translating ambiguous requirements given by people who don’t really know what they want. Very little of my day to day is actually about the text I type into my editor, but rather the problem solving that goes on in my mind. Visual languages don’t magically make that go away, they just represent the code in a different form. Sometimes this can be really useful (visual languages make flow explicit and I personally tend to think in “boxes and lines” anyway), but often thats not the biggest roadblock. Often the roadblock isn’t the code at all.
"A picture is worth a thousand words..." When doing presentations or writing, I make a lot of effort to visualize what I'm trying to communicate, as it really helps making sense of all the words.
I work for a low-code, no-code vendor. We usually approach new features by first defining a DSL for a need, and than have one or more visual editors for these DSL. Every part of your application is still customizable (Java, typescript, react widgets, etc), or you can just call a microservice built in another stack.
I was pretty young back then but I do remember a lot of these things being driving forces behind 4GL and 5GL languages. I played with a lot of these things because I was just getting into programming and I was still at the "syntax is hard, maybe what I need is a simpler language" phase...
A lot of these things failed for reasons that are, I think, fundamentally unavoidable if your goal is to not learn anything and just do it:
- Tools that emphasize (or function exclusively based on) configuration over over code are limited by things that you can configure. As soon as you stray beyond that, you not only have to code, but you have to code for a system that has a lot of implicit behaviour. That's a hellish experience if you're an inexperienced programmer. Figuring out why your code produces a result other than what you expected is hard enough. Figuring out why your code produces a result other than what you expected because there's a default configuration flag that alters its behaviour (or, worse, that alters the result after your code correctly computes it) is way more complicated.
- Tracking changes in systems that emphasize (or function exclusively based on) configuration over code is insanely difficult, and reverting systems back to a specific state is pretty hard, too. This may be less of a problem today, in the age of containers, I guess.
- Validating changes in such systems is even more difficult than that, because a lot of the logic is implicit and hidden from sight. If you have to make a change in a system you're not too familiar with, reading the code can give you an idea about what behaviour would be affected. If your change breaks something, reading the code can help you debug things. If there's no code to read, or you can't do it in the first place, and changing the header of a column just broke your reporting tool, you're going to spend a few fun evenings at the office poking it with a stick until it un-breaks.
- Tools that emphasize integration of separate tools over coding result in systems that aren't very fun to maintain. Changes in the way components interface were a problem even in the early 00s, and they weren't on a rolling/continuous release schedule, weren't delivered "as a service", and "move fast and break things" was just called being sloppy. Integrating a dozen third-party modules today requires full-time maintenance, from someone who can definitely code.
I do think that making it possible for end-users to automate their work is a direction worth pursuing, but this isn't the way to do it, and I think there's a wealth of lessons from two decades of failures to learn.
IMHO, some broad directions worth pursuing would be:
- A simpler and more stable development framework. Keeping up with JS and CSS frameworks (many of which exist precisely because pure JS and CSS are pretty painful to use if you want to develop a desktop-like application) is hard even for people who use them professionally. There's no way you can ask business people to keep up with that. A more stable framework, that hides the fact that browsers were never meant for application development well enough (even if that means less flexibility) could go a long way towards making things easier.
- Better DSL integration in business tools. A lot of the business logic is written in the same language as, and embedded in, the overall application logic. That doesn't necessarily have to be the case. Template engines are sufficiently advanced today that you can do a lot with them, and I've seen people without much programming knowledge being able to use them productively.
- Oh and if we're being honest: better code quality where code really can't be eschewed. Virtually every business app I've seen in the last ten years is the same story: a user needs a change, they can articulate it perfectly well, they can describe the logic in pretty good details, sometimes they can even gi...
Re: "A simpler and more stable development framework. Keeping up with JS and CSS frameworks (many of which exist precisely because pure JS and CSS are pretty painful to use if you want to develop a desktop-like application) is hard even for people who use them professionally. There's no way you can ask business people to keep up with that. A more stable framework, that hides the fact that browsers were never meant for application development well enough (even if that means less flexibility) could go a long way towards making things easier."
Indeed! We need a GUI/desktop-oriented markup standard for in-house and custom CRUD. It's a big market that shouldn't ignored at the expense of other markets (such as sales-oriented websites).
All the companies who want a chunk of Microsoft's business should get together and help define such a standard. Google, IBM, Oracle, Amazon, Apple, do you hear that? The MS pie is waiting to be sliced up for YOUR benefit. Get on it!
> Increasingly popular in the last couple of years, I think 2020 is going to be the year of “no code”: the movement that say you can write business logic and even entire applications without having the training of a software developer.
Last couple of years? I'm sorry, how long have you been in the industry because the industry has talked about that forever.
As a marketer, I always look for no code solutions first. API integrations? Use Zapier. Email form integration? Sumo or similar. Triggers? Google tag manager. Etc. The reason being that the dev team at any company never has time for new projects.
So, instead of "learning a new language", they're "configuring a new integration"? Guess how much these differ...spoiler: two marketing labels for the same thing.
I can train one of my juniors in how zapier works in an afternoon. Teaching them (or myself) a programming language would take years and be more error prone.
I can teach IF, FOR, and the basics of python in a week. I can teach ruby in about the same. For what they are going to need for a low code solution, that's enough. You don't need to teach all of programming - only a subset that would be covered in a low/no code solution.
If you don't believe this, look at how many non-CS professionals have learned VBA as their excel-fu reached a limit. Even if it's not clean to start, the natural human curiosity starts to take over.
One of the better programmers I ever knew had a high school education and was working in an airplane maintenance facility when he was frustrated with the tools he had and just started learning VBA on his own.
I think you might be underestimating what these tools can do. I'm not the person you're replying to, but I have also seen a junior marketing person create a Web form to be sent to clients (using Jotform or similar), have it output to a Google sheet, have Zapier pick it up and move it to Airtable, where he defined a bunch of extra fields for internal staff to annotate the submissions, all while getting notifications when certain conditions were met.
Not only could he not learn enough python in a week to do this, but the professional developers on my team could not do this in a week.
This actually feels very unixish. `form | sheet; crontab: zapier | airtable`. Simple tools that can be simply combined - I feel similar about Tasker, where I can combine various building blocks without worrying about compiling an app. (It does get cumbersome without an IDE)
> I can teach IF, FOR, and the basics of python in a week. I can teach ruby in about the same. For what they are going to need for a low code solution, that's enough. You don't need to teach all of programming - only a subset that would be covered in a low/no code solution.
OK, now what? Do you teach them deployment of those "low code solutions"? Is it another week?
"Oh, now you want to send a notification to Slack? That's a little above basics. What about another week of learning the concept of libraries?"
Yeah I've always read this to be a failure of engineering to produce stuff in time. I wonder if it's a failing of open source that it hasn't gotten to web infrastructure yet.
333 comments
[ 3.6 ms ] story [ 243 ms ] threadE.g. if you could get the end product with Less waiting and miscommunication. I can see that being a sales pitch that resonates
That seems to be the gist of it. SaaS seems to tackle this specific issue by trying to move everything away from the customers in the first place. Don't need sysadmins or software devs(here) if they're in the cloud(over there).
Their pricing model is often advantageous to smaller companies aswell; only paying for what you use, even if that price is ridiculous per unit sold, it still often beats hiring dedicated staff. This effect lessens over time as company grows.
Intelligent subject-matter experts who are non-programmers can build 80 to 90% of their business info capture and reporting requirements inside the walled garden of their chosen platform.
Programmers are called in temporarily to complete the final 10 to 20% of the LowCode app, and integrate with external services.
It's been happening since Excel, through to Wordpress and nowadays splintered into 100's of directions and platforms from Wix to Podio to Notion.so
The problem is that a "problem" is essentially a fractal; it needs a defined accuracy and scope to be solvable. Differing scopes and accuracies again require overhauls of software that would otherwise be acceptable for the same task.
The first 90% of the work takes 90% of the time, and the remaining 10% of the work takes the other 90% of the time!
I think there's some vague point in any project where it goes from being 'easy' to 'hard' to add new stuff. Basically the only factor that matters for productivity is how long you can delay that point. If you just do the first 90% as quickly and cheaply as possible, you're just resigning yourself to hitting that point as early as possible.
The graphic also suggests that there is an inflection point, as you suggest, before where time spent on design really is just slowing you down in the beginning of your project, but also that the costs of waiting too long to switch modes (from doing no design, to doing good design) after you have crossed that line, are substantial and compounding; the longer you wait, the more your lack of good design costs.
And of course, not pictured, is "bad design" which can be even worse than no design. Trying to find that inflection point and put it on your development schedule in advance is also a bit like trying to catch a falling knife (not likely to succeed.)
[1]: https://martinfowler.com/bliki/DesignStaminaHypothesis.html
But to hear it explained that way, it just seems like wishful thinking based on a circular reasoning, that invites an invocation of the rule... "We spend too much on our developer staff, so in the future we have adopted a strategy where we will avoid most of the things that we need a team of developers for, so that our developers have less work to do, so that we can have fewer expensive devs (of which we know we cannot dispose entirely, [because we are subconsciously aware without them, there is no innovation to speak of at all.])"
The problem that "Low Code" or "No Code" addresses is a real one, where devs like myself, (surely not myself, but someone more junior...) confuse poorly architected slipshod solutions for innovative ones.
If we could reliably keep our code as simple as it ought to be, the market for tools like this would probably not be as large as it is.
In other words, the 80/20 rule says the last 20% takes 4x as long as the first 80%. In comparison, the above quote says the last 10% takes just as long as the first 90%. So slightly different.
But saying "the first 90% takes 90% of the time" blatantly ignores these anticipatable unknowns; so it's a much more tongue-in-cheek thing to say.
WordPress is great for low code.
I did my html and in an hour had it working with WordPress.
As other replies have pointed out, the really successful tools are like Excel: They have a real programming language at the heart of them, and they don't try to hide it away.
Disclaimer: I founded and run something you could call a "Low-Code web environment" (https://anvil.works) - but I prefer "Visual Basic for the Web" (or "Web Apps With Nothing but Python"). We built it around the idea that writing code is inevitable - indeed, it's the best way to tell a computer what to do. So don't try to hide it - make it a first-class experience!
For instance, "no-code" website creation offering has done wonders in replacing the "install wordpress on a very crappy cheap host and let it rot with vulnerable plugins" paradigm.
Perhaps this was an impedance mismatch: "web requires coding" - it mostly doesn't, most people would be okay with a better HTML editor, and providing that via WP was a historical quirk.
Sure you can replace 4-5 lines of python with some box-based UI rule system, but anybody who’s not first week out of a 2 week coding boot-camp knows that the devil is in the detail. What if instead of “display error” it’s “try again if it’s a mail server error up to a maximum of 4 tries then email the administrator and save debugging info”
Then what about a loop? Have you ever tried to debug a loop in a UI programming environment? What about a complex loop with custom data types and no ability to see a stack trace or variable list? You gotta put print dialogs and system exits all over the place, and oh, the print dialog only prints a small string? Now you gotta do 1 variable at a time, 200 times to debug. Now I’m showing this to the “non-coder” who’s thinking “this is a giant headache” - and you know what??? HE IS RIGHT, because we have both been forced to use this crappy, blunt tool. Wasn’t this supposed to make things EASIER? Now the business guy AND the programmer are tied up trying to shoehorn what would otherwise be trivial for the programmer into this weeks novelty rinky-dink “no code” tool
Ui drag and drop replacements only work for trivial examples, or they become a giant unmaintainable spaghetti diagram that’s so complex you can’t even follow the lines, let alone understand program control flow.
The fundamental problem with existing software is composability. Us geeks have it at the command line, but regular users can’t pipe their brower through grep them to their printer,
Users are stuck with the fixed options available at software design time, if we could standardise a composable interface on all software (I don’t think “bytes” is the right abstraction for this, it’s too low level) then users can start dynamically composing their own solutions, which will take a decent shift in thinking for most people - but a generational cycle will fix it if young kids grow up taking composability for granted
The main culprits are Ansible/Salt and all the string-templating based tools for Kubernetes (Helm/Kustomize/...).
Especially with tools like Helm I believe we reached peak insanity levels. Instead of using a general purpose or configuration-specific (like Jsonnet/Cue/Dhall) programming language to build and then emit in-memory objects to YAML manifests, the industry is using YAML to define templated YAML and then parametrize this templating with even more YAML.
Now we just write complex declarative configuration with no debugging facilities, a non-existent type system, inversion of control that usually ends up working against us and no way to interact with external data apart from stringing everything together with fragile shell scripts. But hey, there's no need to write a single line of Go/Python/Java/Ruby!
General purpose programing languages are getting more expressive by the day, why do we use data serialization languages instead for configs? it doesn't make any sense.
Configuration is code not data.
These are people that by and large don't want to code, not saying that they can't or won't.
To be fair this has been in Windows shops, where scripting has only recently (last 5-10 years) taken off, so you've got a lot of windows admins that the closest they've been to code is Batch scripting with a bit of Powershell. This is a big change for them
As it happens i read about pulumi recently and I've put it on mt list of todo things, but I can't see that I'll be able to sell it to our team and our team is blessed (cursed?) with three former developers
I'm on a relatively new team kind of like that (it's not a former Ops team but most of the team was pulled from Ops/DBA/analysis teams, and fits the description, and it's not a really a DevOps but more of a Dev+Ops team) and the general reaction of the team to being introduceed to the AWS CDK has been “we need to move to that as soon as we can”, even from people who very vocally never wanted to be programmers. And that's with, in many cases, a couple months experience with both programming and YAML IAC in the form of CloudFormation.
I disagree. That's the stereotype that tool builders have of such people. Good ops people have always loved coding, or we wouldn't be living on the mountains of Bash scripts also known as "Linux distributions".
(Besides, people who don't like to code won't like writing tons of declarative markup either. So there is little point in the current approach either way.)
As to the declarative markup, for instance Azure Devops still doesn't have feature parity between YAML pipelines and classic pipelines, so while you could well be right about the same resistance to yaml, it's not, necessarily an issue yet.
I've only really skimmed their documentation, but the idea that calling 'new' against a VM class instantiates a VM in production seems to be to magical for my taste, and might be an indication that it's yet another product that targets the happy path more than what we tend to experience in production: failures.
You know, once upon a time, we understood that declarative approaches to software engineering were superior to imperative approaches, when declarative approaches are feasible. Declarative approaches are much safer and easier to test, at a cost of only being able to express what the tool accepting the declarative approach can understand. Imperative approaches are strictly worse for any problem set where a declarative approach solves the problem within performance requirements. The additional expressiveness of languages like Pulumi is the last thing I want.
YAML is a horrible language for declarative system configuration because a) any sufficiently complex system will require you to generate your declarative codebase in the name of maintainability, b) generating code for any language where whitespace is significant will lead you to an early death, and c) stringly-typed languages are fundamentally unmaintainable at sufficient scale. But this is not an indictment of a declarative approach! It is an indictment of YAML.
> Configuration is code not data.
Data > code. Data does not need to be debugged. The best code you can have is deleted code - deleted code does not need to be maintained, updated, or patched. Code is a necessary evil we write in order to build operable systems, not a virtue in and of itself.
That data you are talking about does need to be debugged, like Helm charts and pipeline definitions. Sure data is better, but config is code, not data.
Whether the generated declarative output produces the expected behavior on the part of the tool interpreting the declarative output is part of the tool's contract, not the generator or the declarative output. If you need to check the tool's behavior then either a) you wrote the tool or b) you're writing an acceptance test for the tool, which is an entirely different endeavor.
There's nothing that prevents you from writing a unit test that runs `helm template` directly to check whether a given chart with given values will produce a given set of YAML files.
Config is both. Config variables are data. The code that accesses and uses those variables is...well...code. they should be kept separate. Like any other code and data. Config isn't a separate special entity, it's just another part of the program. The data part should be represented as such and the code part should be code. Trying to combine them and create a special 'config' language is mistake.
Allowing computation can alleviate some of those problems, whether it's done "declaratively" (e.g. prolog-like, as in cue) or not (e.g. like idealised algol with memory cells).
The main reason to avoid jumping to something like Python isn't that it's "not declarative"; it's that Python is impure, and hence may give different results on each run (depending on external state, random number generators, etc.). Python can also perform arbitrary external effects, like deleting files, which is another manifestation of impurity that we'd generally like to avoid in config.
tl;dr The problem isn't the style of computation, it's the available primitives. Don't add non-deterministic or externally-visible effects to the language, and it wouldn't really matter to me whether it's "declarative" or not.
The more things change, the more they stay the same.
The pendulum is swinging back towards scripting languages. But give it a few years, and we'll be railing against scripting languages for not being idempotent enough, and moving back to the latest version of YAML and XML (perhaps we'll go with TOML this time) with custom interpreters.
We have seen this half a dozen times already, between turing complete DSLs in ruby, to plain bash, perl, and python scripts. The other side are the DSLs written using YAML, JSON, and XML (and every other config language written in history).
Could you share some details on that? A quick Google search didn't reveal anything about major changes to the SDK.
https://aws.amazon.com/cdk/
As any Lisper knows, code is data is code.
(It's the same with SQL, you describe what you want back rather than how its achieved. A declarative approach works fairly well there.)
What would be the benefit of adding a declaritive language into the mix over YAML?
YAML is not typed and you can basically do whatever. The worst of all worlds.
Emacs is configured using Lisp. Because of that it is amazingly configurable. XMonad uses Haskell, which gives types to avoid lots of error cases.
The thing is providing an actually programming language doesn't remove anything specially if the same config can be written as cleanly.
And you would avoid "YAML templates for creating YAML", when you actually need to process some data (even if it's just for pre/suffix creation in names). Secrets retrieval is another thing that you also need to do and template.
Also, YAML is a terrible to parse language, with can give out weird error cases. Other languages compilers/interpreters are more mature.
And ofc, if you provide SDKs for your IaC tool, you should be able to use the language that your developers are more familiar with. Taking advantage of the good practices their are used to. Don't limit with "declarative languages". Use a programing language that make more sense, and leave data languages for data.
The capability to readily define, store in libraries, and use reusable abstractions that apply within a configuration or across multiple individual configurations.
It's a hard to tell where marelle ends and the config begins, since it's all just prolog.
Thus, it is very easy to get in a situation where an Ansible playbook applied against two machines with slightly different production history will result in very different behaviour.
If you want real declarative configuration management, try Nix/NixOS.
Terraform on the other hand does have a concept of ownership, diff-ing, and applying changes. It takes some work as you now need to track state, but I've been very happy with Terraform.
Of course, you could write code to generate your YAML, but the tooling is _not_ going to help you with that today.
Maven and Gradle are examples of each of these methods -- both build up an internal model of the build, but while Maven uses XML, Gradle uses a Groozy DSL.
Sure, that's true with many of these, so what?
The problem isn't that the languages are declarative—functional code is declarative.
The problem is that they are extremely limited in their expressive capabilities, so that it is much more complex and error prone to describe the final state in them than it would be—even in a declarative style specifying the final configuration—in a more complete language than YAML (or, in many cases, a language essentially limited to JSON’s expressive capability even if it also supports a YAML serialization.)
> It's the same with SQL, you describe what you want back rather than how its achieved.
YAML would be an inadequate alternative for SQL’s role, too.
And LUA has its own hype, just not in configuration scenarios.
Here in lie much of the ”devops” problem, imo, as coders seem to want to allow easy configuration management through “simple“ declarations, inventing almost a new language in the process.
Having worked for 20 years with systems/configuration management, mainly as a developer I can tell many coders have not. Not at scale, and not supporting 100s of different services simultaneously. Hence square wheels gets re-invented.
To be rid of all yaml templating and loosely coupled technical integrations you will have to treat config/service delivery/ci/cd/what-have-you as a business domain of it’s own, and develop it the same way.
I guess we agree, completely perhaps?! :)
I’ve been fortunate to have been able to work everything from small upstart to big corporate enterprises and to me this is more true now than ever.
As a developer I build my own version of a CMDB, I do not use crazy templating - I write an API, that leverages the CMDB and produces sane output. It’s still configuration as code, just something that is easier to scale and adapt.
Guess I’m only disagreeing on whom to blame for this mess.
But at least there is the AWS CDK and Pulumi now to enable “infrastructure as code” as code.
As a big proponent of Dhall, I gotta say, probably the primary reason for that at this point is due to a lack of language bindings. Most tools in the Kubernetes ecosystem are written in Go. Currently, there is no official Go language binding for Dhall - one implementation[1] is pretty close, but the marshalling features need some work, and it's not the author's day job. The only way to get Dhall configuration into a Go program today is to either shell out and call the Haskell-based reference implementation directly or to script your Go binary such that the Haskell-based reference implementation translates the Dhall configuration to JSON and then feeds that into the Go program. Even that's not ideal - you end up maintaining your schema in Go code and in Dhall simultaneously.
I very much believe that Dhall will solve the stringly-typed insanity which you refer to, but the language is not quite there yet. While I'd love for some of the Kubernetes core developers to step up, I mean, I can understand people's unwillingness to adopt something that isn't 100% perfectly well-supported and handed to them on a silver platter.
[1]: https://github.com/philandstuff/dhall-golang
Using Dhall to create the YML you will use isn't great, but it's quite possible today and is much better than using YAML to script a YAML generator that will read some more YAML to create the YAML you will use.
I guess some people simply like YAML.
If we step back, there are a few different strategies for dealing with operational logic. From least scalable to most (roughly):
1. Human processes (ex: checklist)
2. In the config itself (ex: Kubernetes' YAML)
3. A config generator (ex: Helm, Kustomize)
4. Software (ex: Kubernetes Operator)
I see a lot of people get stuck doing one for too long.
When doing one becomes unwieldy, it's time to consider the next. That or find a way to reduce the need for all that operational logic.
The point of all this is that software configuration is never a simple declaration. It is always a mess of behaviors and derived values.
I am not sure I totally agree, but it at least correct enough to always break something. And adding abstraction layers just because you choose to use an underpowered notation at the bottom isn't a good practice.
Language doesn't matter. What matters is the attitude of tool builders that everything should "simply" be described as data. When that turns out to be insufficient, as it inevitably does, hacks are introduced and sooner or later you end up with crippled and idiosyncratic pseudo-languages.
IMHO a big part of the problem is that the companies involved are actively incentivized to justify their existence by making things more complicated instead of less complicated. If things are too simple, nobody needs their consulting, training, support, etc. Worse most of these companies are competing for attention and typically only provide part of the solution instead of the whole solution. So there's a lot of money in cross integrating multiple complicated solutions from different companies. Indeed many of the companies involved are serial offenders when it comes to this. As soon as you get companies like Red Hat, Amazon, Oracle, etc. get interested in stuff, brace yourself for some convoluted vendor lockin. That's basically what happened to Kubernetes.
When it comes to languages, I'd love something that has a compiler and auto complete. I'd also like something that has a notion of internal domain specific languages. IMHO Typescript, Kotlin or Rust could work for this. The point of this would be leveraging a type system for static checks and code completion. That kind of rules out dynamic languages like javascript, python, or ruby (all of which have been used in devops in the past). They are nice but not nice enough.
However, typescript has enough static typing that you get some meaningful autocomplete. Also, it's already popular in the node.js world (i.e. lots of stuff available to integrate). Kotlin would also be able to fit in that world since there's a transpiler to javascript, it can utilize typescript type definitions and it integrates with node.js and npm. Rust would be a bit of an outlier here and probably a bit too much in terms of language complexity for the average yaml loving devops type with a mere few years of full stack experience. With Kotlin, the transition of gradle from groovy to Kotlin has been interesting. Groovy basically is a dynamically typed language and they've slowly been replacing it with the more strictly type Kotlin. That sort of stabilized with v5 and with v6 it got usable for a lot of projects and recent updates to Intellij have improved how it is able to support developers with e.g. code completion and other features. Something like that aimed at devops could work.
DSC or pure powershell has bunch of useful tools and a real programming language to use in between. Yaml like configuration can be achieved with nested HashTables that have almost equivalent readability without loosing any of the devlopment capabilities.
Sometimes one doesn't "need" a coder because the system is such that it wouldn't do you any good anyway.
Programmers never go away, though. Besides the need to write the customizations that the higher level languages miss, there is the need for disciplined thinking and testing. No matter how simple the tools become, the need for these remain.
[1] https://en.wikipedia.org/wiki/The_Last_One_(software)
Around 1960 some people seriously claimed that within about 5 years there would be no more professional programmers because with this new language, everyone could write the software they need themselves, since it was so easy to use.
The language was COBOL.
Oh, and look, this one still seems to be around: http://www.makeyourownsoftware.com/
Of course that prediction seems quaint now, but I posit that the prediction failed because they greatly underestimated the increase in demand of software as much as overestimated the expressiveness/productivity increase of COBOL (and later systems).
Heck, considering what a professional programmers job might have been like in the 50s, its not far fetched at all that such profession indeed has disappeared as modern programmers work at such a different level of abstraction
But I think the main thing it failed to take into account is more how hard it is to translate business requirements into complete and unambiguous instructions.
Here are some old INFO-COBOL messages archived in the MIT-AI HUMOR directory:
http://its.svensson.org/HUMOR%3bINFO%20COBOL
Then there was The TTY of Geoffrey S. Goodfellow's spin-off, the specialized "DB-LOVERS" mailing list, just for dead baby jokes.
https://news.ycombinator.com/item?id=8418591
Speaking of COBOL jokes:
https://medium.com/@donhopkins/cobol-forever-1a49f7d28a39
Episode of Command Line Heroes by Red Hat about COBOL: https://www.redhat.com/en/command-line-heroes/season-3/the-i...
I think it's a little unfair to characterize COBOL as a failure in that regard. It tremendously increased the accessibility and use of programming and computing in general by way of consequence; it's been instrumental in allowing the programmer population to grow massively.
Granted, extraordinary superlative claims never materialize, but the intent, the vision is important ime. Especially in business settings.
I dabble in graphical programming languages from time-to-time, and one feature they all share is the editing environment for code makes entire categories of syntax error impossible; there is no way in the language's design to pass a string to a function that only accepts a number, for example, because the "blocks just don't fit together." It's a level of integration between the space of all possible arrangements of elements and the set of arrangements that constitute valid programs that I see text-based IDEs approach, but struggle to catch up with. And I suspect part of the challenge is that as a tool for describing programs, sequential text has too much dimensionality; the set of strings of sequential text is much, much larger than the set of valid programs, and it's easy to put text sequences together that aren't valid.
Which is easily achieved by the first typed language that comes to hand, no?
It's possible, with many languages, to write IDEs that will make this hard, but I've yet to find one that makes it impossible. Certainly not in the same way that, for example, Scratch will simply refuse to let the offending blocks click together. I certainly don't advocate transitioning from text languages to Scratch, but I think there's meat on the bones of asking the question "Why, when I'm editing code in text-based languages, am I even allowed to reference a variable that is demonstrably the wrong type? What benefit is that gaining me?" Because I think the answer in a lot of cases is "No real benefit; editing, typechecking, and compilation have just historically been disjoint concerns with no feedback channel because writing those is hard."
Apples to apples would mean comparing your Scratch experience with a nice IDE for a typed language.
Even more I don't believe in plain monospaced ASCII being the ultimate format for code. Luckily there I know one example that goes at least a bit further: Fortress[2], a language from Sun that had richer rendering format available (although the underlying form was still afaik textual). And of course APL is another example, albeit bit less easily approachable. Raku also has some cute tricks (of course it does) with unicode characters[3], but they are more really just tricks that radical revolution in design.
There are also lots of other interesting ideas on how to format and layout code in the research, just one random example is "code bubbles"/"debugger canvas"[4]
While I think all this and so much more has great potential, there is huge cultural entrenchment around simple text based programming that seems unlikely to be overcome any time soon. As for graphical programming, I think the common failure there is being often also heavily mouse-driven, while keyboard is really powerful input device.
[1] https://en.wikipedia.org/wiki/Structure_editor also known as projectional editor
[2] https://web.archive.org/web/20060819201513/http://research.s... has some examples, slide 33
[3] https://docs.raku.org/language/unicode_ascii for example "The atomic operators have U+269B ATOM SYMBOL incorporated into them. Their ASCII equivalents are ordinary subroutines, not operators". Obviously.
[4] https://www.microsoft.com/en-us/research/publication/debugge... paper has few screenshots
Except for the short-circuiting operators (such as || and &&) and the assignment operator, all operators in Raku are just subs with a special name. Adding your own operator to the language is as simple as adding a subroutine, e.g.:
I'm hoping someone can close the gap and bring us a graphical language with a robust keyboard interface to navigate through it and edit it, with the advantage of strong edit-time validation excluding invalid programs. If someone can close the gap, it'd be a hell of a thing to see.
I strongly believe software application design is fundamentally closer to architectural design than the kind of work done in a purely textual realm — say, writing a novel or a research paper. But it's a really hard nut to crack.
I hope CASE today is like AI and neural nets were in early 2000s — a bit of a laughing stock, "something people in the 1980s wasted a lot of time on but nowadays everyone knows it doesn't work."
By the way, this is an anti-pattern known as a Turing tarpit: https://en.wikipedia.org/wiki/Turing_tarpit
There are also a large number of projects - maybe majority? - that never reach that level of complexity; and the "no/low code" solution (like Excel, Access, etc.) enabled a non-engineer to solve a business problem without hiring any engineers.
That's where these kinds of systems shine, if done right; allow a "non-engineer" who has a logical mind / the engineering tao to create solutions without having to learn traditional development toolchain.
And that's how I view my job as a software developer: clarifying ideas.
Any "No Code" tool is still going to either force you to clarify your ideas, or have a large amount of assumptions. "Idea People" and "Business" don't like that, so they'll probably end up delegating the use of "No Code" tools to programmers of some sort.
All are examples of domain specific tools that allow the user to specify their intention in a non-ambiguous way. And they also allow the user to think about and experiment with the problem space.
I think what we need is something akin to this. The "business logic" that we are talking about here is to me a non-infinite domain. It should be possible to boil it down into a domain specific tool that is more helpful than a general purpose programming language.
I will resonantly disagree here. Math is successful exactly because each time it had a rule that was problematic, people just extended it.
And the success of modern (20th+ century) Math is caused exactly by the fact that we got an inifinitely extensible language, so nobody has to ever break it again anymore.
Or programming languages.
I work at a large non-profit. I'm not a coder, but I'm IT literate, and know enough about database design to not do absolutely stupid things. I'm happy to document processes enjoy clarifying ideas.
We use Sharepoint. In many many respects Sharepoint is detestable garbage, but I have managed to create some really quite complex automated workflows which are saving people in the organisation a lot of time, using Sharepoint Designer (no coding). It's documented, fairly robust and I wouldn't have been able to write it in a conventional language.
I'd say you're at least some kind of coder. My point is that there will always be room in an organization for people like us, who aren't afraid to go down and use our tools to the fullest extent, to save "people in the organization" enormous amounts of time. These tools can be code or something else, but the point is clarifying ideas. The exact tool you use doesn't matter.
"No Code" is not an existential threat to developers, it's just another programming language.
Clarifying processes
I'd wager that the vast majority of businesses have no idea how their internal processes actually operate, what steps they take, what steps are already automated, what steps are not automated but could be, and what steps don't seem like steps but are actually super-important parts of the overall process.
I'm not an expert in the domain, but a few employers ago I worked for a company that was heavily involved in Six Sigma. Yes, it was a management buzzword. In many cases it was probably being used wrong. Or was being applied in a manner orthogonal to the problem. Or...any number of other things.
But one thing we studied in our "off time" (the company was a focused membership organization - we had magazines, conferences, everything) was how to apply 6S to our own business (you'd think that would have been done from the beginning - you'd be wrong). One thing we looked into, and attempted to understand and apply, was business process mapping.
That is - everything (and more) that I noted above - in various forms of flow-charting and other process mapping diagram systems, mostly done by hand, as it was easier for multiple people to see the processes and reason about them. Once we had things relatively "tacked down", we would convert those over to an electronic form.
It was an interesting exercise, and we never completely finished it before I moved on (the company went belly up soon after I left, as I was the only SWE left - it wasn't a large business). But we did notice in the exercise some interesting things:
1. If your business process flowchart looks messy, and can't be "untangled" - there are problems with your process.
2. Similar to #1 - if the flowchart looks unbalanced, even after untangling, there may be issues with the process as a whole.
3. Process flow lines that cross should be avoided; usually this is just a result of how things are arranged, but if you re-arrange things and still find a lot of criss-crossing lines, and can't make them not cross - again, issues may be there.
4. Soft processes are real processes - and trips things up. These are things where you might do something "out of the loop" or talk to somebody about something - but it doesn't seem like a real part of the process - but if it weren't done - the whole thing would break. Usually, these kinds of things aren't uncovered until one or another party leaves, either permanently or while "on vacation". Sometimes, the issue doesn't appear until some automation is put in that leaves that soft-process out, or unintentionally goes around it - then it can stick out like a sore thumb. Identifying these processes - and they can be difficult to identify, as sometimes even the person doing it doesn't know they do it, as you talk to them about their role in the overall process. You have to watch them do it.
This last one - there's a story I once read, I'll condense it as best as possible:
A woman brings her car into the shop complaining that the vehicle isn't running well after driving it a while. She gets in it to go to work, and at first it's ok, but within a mile or so it doesn't run very well. She doesn't know what is wrong. The mechanic looks at it, starts it up, it seems like it runs well. He tries it in the morning, everything is ok. He calls the owner and she comes into the shop and gets her car, but returns the next day complaining that it is still running strange. The mechanic asks if he can take a ride with her, to show him the problem. She says sure, they get inside the car, and as he sits down in the passenger seat, he sees her pull out the choke and hang her purse on it. It turns out that her previous car had a special pull out "hook" for just that purpose, and she didn't know. After the mechanic explained the problem, she had no idea, but the problem wa...
https://www.cgl.ucsf.edu/Outreach/pc204/NoSilverBullet.html
Read and inwardly digest
I think this line in particular is a good TL;DR of the issues discussed in the linked article:
> The complexity of software is an essential property, not an accidental one. Hence descriptions of a software entity that abstract away its complexity often abstract away its essence.
In particular, the attractiveness of no-code should not be that one does not have to have in-house software development, but that one has less technical debt and thus smaller technical interest payments. Businesses will always have problems with computers, because computers are rigid and unyielding, while businesspeople are soft and compromising.
It is all to easy to read the beginning few paragraphs as the sourest of grapes: The businessperson, having embraced fax, email, paperless, Web, and mobile, is nonetheless no closer to having embraced computer. The "traditional sense" of creating software is derided as "expensive, in short supply, and fundamentally [not quick at] produc[ing] things." But that is all explained neatly by market forces: Developers are expensive because competency is rare because understanding is low because computerizing is a painful commitment because operationalizing a business is equivalent to automating it away. Computers reveal the rent-seeking and capitalization simply by being themselves on their own.
Visual Basic was released many years later, and looked very different from the original BASIC.
Some people even used it to build GUIs for applications where the bulk of the code was written in another language.
VBA was in all the Office applications... Excel, Word, Powerpoint, Access...
A big pile of Zapier gunk might be brittle, but I think tools like it are a natural progression in a society where everything is dependent on computers. To me it's part of "Everyone should learn to code".
"No Code" solutions are like asking your user to communicate using pictographs. It's possible, but language allows users to communicate in better detail faster. In school I learned how to write, I'm probably not anywhere close to writing a novel. I'm a terrible writer, but I can write an email. Frankly, that get's me pretty far.
I looked on Amazon but there are only used paperbacks and no Kindle edition. But I saw from the cover that it was a Pragmatic Press book, so looked for it there and they have a no-DRM ebook of the second edition - for a lot less money than the used copies on Amazon!
https://pragprog.com/book/ppmetr2/metaprogramming-ruby-2
My impression is that a good part of it for many is not making them realize that they are "programming" until they've already accepted that they can do it, because otherwise they "know" that it is too difficult.
This is something that frustrates me in general, and I'm sure others, too:
That there seems to be among a certain population of people a mindset that declares failure before they've even tried. Or, they try, but at the first hint of failure or trouble, they declare that they can't do it, and stop.
So what is different about those people who don't do this? Why do they instead take up new challenges, and when they fail, try again. When they run up against difficulty, they step back, think about their options, perhaps consult experts in the domain, and continue on?
And how do we get the former group to join the latter?
I know there isn't an easy answer to this, if there is one at all; I know I'm not the first to observe this issue either - it's likely something that has been observed and wondered upon for thousands of years.
...but nonetheless, it continues to be frustrating.
Most people don’t care enough though and life’s too short to spend on something when other things are more important to you.
You just described my three year old's eating habits.
There are so many commercial successes for this approach: CAD, MATLAB, Simulink, LabVIEW, Dymola, Excel (?)
The biggest issue with many of these tools is that they tend to be closed source, proprietary formats, onerous licensing terms, not easily extended and aren't easy to deploy into an automated production workflow.
Some are addressing this with an option to export a compiled binary, but many try to up sell you complete ecosystems (PLM) to keep you locked into their proprietary formats. This tends to frustrate devs.
Mendix (https://www.mendix.com) does a lot of that well but as you pointed out it's proprietary.
If we look at history, successful predecessors like C, Java and Python (sorted by difficulty) are all open standards.
I think the next low/no code platform to open their specifications wins the race.
Disclaimer: I've worked for Mendix.
Learning a skill takes time and tenacity. Years ago, I tried to learn guitar, but gave up after a few months because progress was too slow for me. I was impatient and not motivated enough and therefore ultimately didn’t get anywhere. Two years ago, I decided I wanted to learn sleight of hand card “magic”. There was one flourish in particular that I just couldn’t do, but I kept trying anyway. Day after day, I couldn’t do it and then one day I realised I could. The only difference between that and guitar is that I kept at it and out the effort in.
Sure, some people are predisposed to certain things which is a bit of a shortcut (I definitely found programming easier to learn than card magic), but I believe that most people can learn most things, if they have sufficient motivation and put in the time and effort (I include finding a way that works for you as part if effort, just doing something repeatedly may not be enough on its own, as they say: “practice makes permanent; perfect practice makes perfect” — ie be careful of learning bad habits that may get in your way)
I’m personally not against visual programming and have had some good experiences with it, but the name “no code” in my opinion completely misses the point: its still code (and programming). The text was never the hardest part, so by eliminating that, you’re not really winning much. The hard part is the logic, calculations, data manipulation and translating ambiguous requirements given by people who don’t really know what they want. Very little of my day to day is actually about the text I type into my editor, but rather the problem solving that goes on in my mind. Visual languages don’t magically make that go away, they just represent the code in a different form. Sometimes this can be really useful (visual languages make flow explicit and I personally tend to think in “boxes and lines” anyway), but often thats not the biggest roadblock. Often the roadblock isn’t the code at all.
[1] https://www.tradingview.com/pine-script-docs/en/v4/index.htm...
I work for a low-code, no-code vendor. We usually approach new features by first defining a DSL for a need, and than have one or more visual editors for these DSL. Every part of your application is still customizable (Java, typescript, react widgets, etc), or you can just call a microservice built in another stack.
Having worked on that space, I find the potential users (that are not developers) to be pretty limited, YMMV
A lot of these things failed for reasons that are, I think, fundamentally unavoidable if your goal is to not learn anything and just do it:
- Tools that emphasize (or function exclusively based on) configuration over over code are limited by things that you can configure. As soon as you stray beyond that, you not only have to code, but you have to code for a system that has a lot of implicit behaviour. That's a hellish experience if you're an inexperienced programmer. Figuring out why your code produces a result other than what you expected is hard enough. Figuring out why your code produces a result other than what you expected because there's a default configuration flag that alters its behaviour (or, worse, that alters the result after your code correctly computes it) is way more complicated.
- Tracking changes in systems that emphasize (or function exclusively based on) configuration over code is insanely difficult, and reverting systems back to a specific state is pretty hard, too. This may be less of a problem today, in the age of containers, I guess.
- Validating changes in such systems is even more difficult than that, because a lot of the logic is implicit and hidden from sight. If you have to make a change in a system you're not too familiar with, reading the code can give you an idea about what behaviour would be affected. If your change breaks something, reading the code can help you debug things. If there's no code to read, or you can't do it in the first place, and changing the header of a column just broke your reporting tool, you're going to spend a few fun evenings at the office poking it with a stick until it un-breaks.
- Tools that emphasize integration of separate tools over coding result in systems that aren't very fun to maintain. Changes in the way components interface were a problem even in the early 00s, and they weren't on a rolling/continuous release schedule, weren't delivered "as a service", and "move fast and break things" was just called being sloppy. Integrating a dozen third-party modules today requires full-time maintenance, from someone who can definitely code.
I do think that making it possible for end-users to automate their work is a direction worth pursuing, but this isn't the way to do it, and I think there's a wealth of lessons from two decades of failures to learn.
IMHO, some broad directions worth pursuing would be:
- A simpler and more stable development framework. Keeping up with JS and CSS frameworks (many of which exist precisely because pure JS and CSS are pretty painful to use if you want to develop a desktop-like application) is hard even for people who use them professionally. There's no way you can ask business people to keep up with that. A more stable framework, that hides the fact that browsers were never meant for application development well enough (even if that means less flexibility) could go a long way towards making things easier.
- Better DSL integration in business tools. A lot of the business logic is written in the same language as, and embedded in, the overall application logic. That doesn't necessarily have to be the case. Template engines are sufficiently advanced today that you can do a lot with them, and I've seen people without much programming knowledge being able to use them productively.
- Oh and if we're being honest: better code quality where code really can't be eschewed. Virtually every business app I've seen in the last ten years is the same story: a user needs a change, they can articulate it perfectly well, they can describe the logic in pretty good details, sometimes they can even gi...
Indeed! We need a GUI/desktop-oriented markup standard for in-house and custom CRUD. It's a big market that shouldn't ignored at the expense of other markets (such as sales-oriented websites).
All the companies who want a chunk of Microsoft's business should get together and help define such a standard. Google, IBM, Oracle, Amazon, Apple, do you hear that? The MS pie is waiting to be sliced up for YOUR benefit. Get on it!
I note there is - strangely - no corresponding "Citizen Management Consultant" role.
https://www.gartner.com/en/information-technology/glossary/c...
in most businesses the business experts are more expensive. wasting their time with building systems can be costly
Last couple of years? I'm sorry, how long have you been in the industry because the industry has talked about that forever.
If you don't believe this, look at how many non-CS professionals have learned VBA as their excel-fu reached a limit. Even if it's not clean to start, the natural human curiosity starts to take over.
One of the better programmers I ever knew had a high school education and was working in an airplane maintenance facility when he was frustrated with the tools he had and just started learning VBA on his own.
Not only could he not learn enough python in a week to do this, but the professional developers on my team could not do this in a week.
OK, now what? Do you teach them deployment of those "low code solutions"? Is it another week?
"Oh, now you want to send a notification to Slack? That's a little above basics. What about another week of learning the concept of libraries?"
Do you see the pattern?