I liked this newsletter post from Aron Korenblit on the no-code movement. The name overstates the problem as being with “code” in workflows, when the problem is really deeper than that:

How we feel about code —and why we want to avoid it— has in fact nothing to do it with code itself. Code is a language that helps us tell inanimate objects what to do so we don’t have to do it. Our real frustration lies with what usually comes with software projects: overblown budgets, long delays and expensive maintenance costs. That’s what we’re saying “no” to, not code.

These issues have nothing to do with code per se but are due to scope creep, poor planning and underestimating difficulty of a task. Issues which, let me tell you, are also very very present in projects using visual development tools (doesn’t have the same ring to it, that’s for sure…).

If what we’re trying communicate is that no-code helps get things done faster, we should elevate that fact in how we name ourselves instead of objecting to code itself.

We notice the same with customers of Fulcrum. Since we’ve been in the “no-code/low-code” market since 2011, we’ve been seeing this for years. Most of our users are tech-literate, but a long way from being developers.

The common approach of all no-code platforms is to make visual user interfaces to represent dictating to the machine what you want it to do (that’s all programming is, after all — a set of instructions guiding the computer on how you want to capture and process inputs to outputs). But even with drag-and-drop, configuration-based interfaces and pretty technical users, there are frequently hurdles to understanding and usage.

One of the biggest challenges is converting squishy, fungible processes that humans deal with easily into specific, articulated actions for the machine to take. I’ve always said that developing a useful software product is an exercise in first automating a workflow, then building in all the exception-handling required to do it reliably in the hundreds of scenarios the user could put it through.

So it’s not only about the code, but also creating visual representations of abstract processes rapidly, then making it easy to iterate and experiment with them.