For at least the past twenty-five years of software development, people have been claiming that, using this tool or that tool, we will be able to build software with “no code,” and that our tools will build code for us. 

The claims have varied with whatever the current technology is. In the 1990s, the idea was that we could have a system which allowed building software entirely with drag-and-drop interfaces. Tools such as Visual Basic, Delphi, PowerBuilder, and even Microsoft Access made people think that this was an achievable dream. It turned out not to be deliverable on its promises. We’ll get more into the “why” later on.

Today we have a new set of tools and a new set of dreams. We have claims that GPT-3-based systems will be able to write code for us. Bubble claims to allow you to build web apps without code. The problem is not that these solutions are without their uses — the problem is that the most dangerous thing you can do with these products is to believe what they are saying about them.

What makes software writing difficult is that we are used to making constant decisions based on how we think the world is expecting us to work. If I ask someone to wash the dishes, I don’t have to get incredibly detailed on how the process works. They can look at a dish, and think about what needs to happen, and do the right thing. I don’t have to explain exactly what I mean by clean or dirty, I don’t have to explain the difference between the plate and something that is dried onto the plate. I don’t have to explain that they shouldn’t break the plates. The person doing the dishes understands all of these things implicitly and can carry them out effectively without a lot of instruction.

Computers, however, are different. Computers have no intuitive notions. They will do what you ask them to, and they will continue to do so whether it “makes sense” or not, because everything makes sense to a computer. When automating a task, very subtle decisions have to be made at every point. What makes a programmer valuable is not their knowledge of any particular language or arcane interface. What makes a programmer valuable is their ability to recognize the extremely subtle impacts of all of their decisions along the way.

I worked with a company recently that had built an app using one of the “no code” automatic app builders. The app worked great and the users loved it. The problem? The hackers loved it, too. It had flaws in the protocol which meant that hackers could easily gain access to personal information about users on the system. The person who created the app had no idea because they were not thinking – and, indeed, were asked (by the tool) not to think – about the subtle impacts of what they were doing. The entire premise behind the tool is that they didn’t need to worry about those subtle details, but that the tool took care of everything.  

My point isn’t that it is impossible to make a secure app with the tool in question, but rather that, in order to do so, one needs to be able to understand the deep implications of what one is building. But the entire premise of the advertising of the tool is that one doesn’t need to be skilled in these things to work it.

Now, as I said, tools like this have their place, but not as replacements for programmers. Tools along these lines can do the following very effectively:

• Reduce the amount of code needed for a project
• Make the code more readable and understandable (both for other programmers and non-programmers)
• Make it so that non-programmers can build “rough drafts” which programmers will take to completion
• Make it so that fairly cookie-cutter applications can be built without code (or with minimal code)

The fact is that even with “no-code” solutions, it is all still code. Drawing an interface is neither more nor less precise than writing out coordinates in text. What’s different is that some forms of input are more efficient than others. Some bundles of logic are more intuitive and effective than others. Some functions are called more often than others. A good interface makes it easy to do the things users are likely to want to do, but still make the hard things possible. 

Earlier in my career I moved a software company from using PHP to using Ruby-on-Rails for software development. This produced a decrease in code size of almost 80%. This is because Ruby-on-Rails automated the common tasks programmers were likely to face. Things that programmers commonly had to do over and over again (like writing database access code), Ruby-on-Rails found ways to autogenerate. What made this especially effective was that the programmers knew precisely what was being automated away. That is, the programmers knew what Ruby-on-Rails was doing, and were glad that the system was doing it, not them. However, the programmers had enough information to recognize the subtle impacts that the Rails platform had on what they were doing, precisely because it was made for those effects to be understandable.

“No code” tools, instead, thrive on telling users that they don’t have to understand what is happening. This is what leads to tragedy in the end. The people building it are under the impression that they don’t need to know what is going on, that the system knows and will take care of it for them. If people see these tools for what they are, and use them simply to reduce the amount of code, then great. I fear (and have seen), however, that people may start to believe the advertising, and think that the computer is able to make all of the decisions they need for them.

In the comic below, the term used is “a comprehensive and precise spec.” That is indeed the essence of programming. What people ask for is not comprehensive or precise. The real task that programmers do is to take specs from people who don’t even know the questions they need to ask, or the holes in their plan that they don’t see, and convert it into a spec that is so precise, even a computer can follow it.

We can assist the programmer to make them more effective with the time they use.  We can remove unnecessary barriers to make it easier to transition non-programmers into programmers. We can make software development tools that make the products of non-developers useful for developers and the products of software development understandable to management. But, when we lie to people and say that it doesn’t take a deep understanding of what is going on to build applications, that leads to trouble.