There is no such thing as “No Code”. Complexity does not just vanish if you replace the way that users interact with it. But that is usually what “No Code” tools are: Pretty UIs that obscure the way things actually work.

(Obviously I am oversimplifying things here and lumping all “No Code” tools together. This is done for rhetorical clarity. I am not claiming that counter-examples do not exist.)

Just because the user interface for a “No Code” tool is visual instead of textual does not say anything about the complexity of the solution to whatever problem that tool targets. Claims of “No Code” tools making some complex task accessible “to anyone” and “without writing code” are just misleading. And here is why:

“Low Code” and “No Code” tools seem to crop up every so often with the promise to make some complicated task accessible to people with no learning required. This has happened multiple times already in the short history of software: “With this new abstraction even non-programmers can write code!”. Afterall, C is just like writing plain English…

In practice this rarely ever works.

Abstract Art

All abstractions are leaky.

The promise of an abstraction in programming is that it hides the complexities of some underlying layer. That can work great by freeing the programmer from the more tedious aspects of that layer. But sadly abstractions leak: At some point the programmer has to deal with the properties and/or behavior of the lower level. If the abstraction is good enough to not completely break down (which also occasionally happens), programmers can sometimes choose to ignore the lower layers in their stack.

As a consequence, piling up layers of abstractions on top of each other with the goal to make things simpler for programmers actually achieves the opposite. While each layer may do a moderately good job of hiding away some amount of the underlying complexity, they are never perfect. Because of leaky abstractions, the higher the technological Tower of Babel becomes, the more leakage accumulates—the result is more complexity, not less.

Inefficiency Rebranded

Tools that are branded as Low-Code or No-Code don’t only suffer from the thin air on Mt. Abstract but like to come with particularly inefficient UIs. They are designed to appeal to non-professionals and pretend to be easy to use. In reality they are usually very limited in what they can do and/or how efficiently they let you do it.

This is mostly related to these tools usually being very focused on a graphical user interface and a mouse-based interaction. This can be adequate from some use-cases, but is inefficient for most. (This is a topic that warrants its own text…)

Clicking buttons, dragging things around and navigating through nested menus is terribly inefficient compared to writing text. GUIs are hard or impossible to automate, do not compose well and usually require more heavy-weight applications. Sure, a good GUI is better than a bad CLI, but good GUIs are few and far between.

“No Code” tools confuse the aesthetics of how to interact with them with the nature of the task at hand: Using a GUI to describe the properties and behavior of a system and having the tool then generate code… Well then why not just write the code yourself? Hiding the aesthetics of a code editor by putting a GUI in front of it, does not change the problem the user wants to solve nor the underlying principles of how the solution will work. “No Code” just changes to UI—for the worse.

Define “Coding”

What I find especially weird is the pride with which “No Code” tools distance themselves from the act of programming. As if that was a good thing. This attitude sometimes even takes the form of an arrogant ignorance—being arrogant or ignorant are both not particularly sympathetic traits, but being arrogant about one’s own ignorance…

The philosophical mistake that the distinction between coders and non-coders makes is that it confuses what programming is all about: Telling a computer, what to do.

Any activity which produces an output that is functionally equivalent to a computer program, is by definition programming.

If someone uses a “No Code” tool to tell a computer, what to do, they are, in some more or less abstract sense of the word, programming. They might be using an inefficient tool to do so, but they are programming nevertheless.

While a “No Code” tool can sometimes be used with less technical expertise and knowledge, sooner or later the activity becomes complex enough to require exactly the same set of skills from the user that any programmer uses. And the more complex the task the more it will attract the kinds of people who are or potentially could be programmers, while repelling the ones who were originally targeted by the promise of “No Code”

Upgrade

Thus, “No Code” tools turn people into coders. Bad ones. Because these tools do not properly teach them the underlying principles and techniques.

If a “No Code” tool serves as an entry-point to get someone interested in programming: that’s awesome! My fear, however, is that instead it gives people wrong ideas about how something really works which can might make it harder for them to break out of the tool’s obligatory contraints. After experiencing the perceived ease with which a “No Code” tool let them do stuff, these users might become even more frustrated, the first time they try to peak behind the curtain and expand their knowledge.

Maybe I am misjudging this. Maybe these tools can successfully nurture their user’s curiosity. The fact that they are often not marketed in such a way, suggests that they are not trying to do that. And why would they? They want to sell a product, not enable their users.

Conclusion

When “No Code” tools are advertised to unskilled users by promising them to be able to tackle complex problems “without coding”, it is usually a bad idea. These tools are either extremely limited or leak abstractions or both. They have inefficient user interfaces and they don’t encourage learning. At best, they turn their users into a kind of programmer that uses a bad tool without understanding what it does.

User empowerment and digital sovereignty require people to understand the technology that affects an increasing number of aspects of their lives. Without this understanding, people are powerless.

The path to enabling and empowering users should include teaching them not to be afraid of code, “No Code” tools do the opposite.