Three years ago I was doing a lot of work around automation platforms and I was asked an interesting question about the limits of no-code platforms:

Does it ever work out really anyway at scale? Or does it always just turn into a big spaghetti mess.

It has been a while since that question was asked but since then I haven't seen anything I think was a particular success in this automation space with regards to managing complexity. In practice I've never seen "no code" work at a large scale, because as discussed in the last article the fearful mindset towards code behind "no code" just sets people up for failure if they are aiming to make a large sale software system. It needs to be said that what is considered to be tractable for solving with software tends to grow over time, but what is considered to be a "large" problem at any point in time tends to not be best solved by the automation "glue" platforms of that time even if in the future with advances in automation platforms that problem later becomes solvable by glue platforms.

At this point in time most people I have encountered who have explicitly bought things called "no-code" tend to be a demographic that don't do their research into the other options available in the software construction space. People decide to make software products and platforms that don't require programmers, or most specifically programming skill, in order to be used all the time in the industry. But to rename GUIs and configuration as "no-code" tends to strongly correlate with a number of other organizational pathologies. One in particular is a distrust of value in technical and programming staff, often people have these fears that such staff are expensive and just aren't worth hiring. Another is financialization corrupting the engineering thought processes of the organization where spending far more on CapEx is preferred to a much lower OpEx spend that also involves hiring some UI/UX people to get the same job done. So it might be the case that something that is functionally the same as "no code" could be successful at scale but the mindset typically associated with "no code" is just such an anathema to successfully scaling up.

The difficulty here, at least on a staffing level, is that making complex scaled software requires software practitioners to be cost-effective. There really isn't any getting around the fact that the professionals who are most skilled at making cost-effective software at large scale, namely software engineers, are the best people to hire to make large scale software. There's a number of sharks waiting to sell products to anyone who wishes this were not so.

What happens when no-code goes too far?

The difficulty comes when you really want the power of writing general purpose software but yet are forced to use a GUI or some other limited system. The barriers to immediate entry from someone with no experience are low, but the barriers to productivity to someone who knows what they are doing can be extremely high. This is a case where you frequently find a Turing Tarpit, a situation that Alan Parlis commented on in Epigrams on Programming:

Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.

So the reason this term is called what it is, is due to a reference to the notion of a Turing complete language a property in which you have enough power to program whatever you want, including other programming languages. In practice however if your first task to do something useful is to first write a more useful programming language with your existing system you are at a severe productivity disadvantage to using a language or system that more immediately lets you do what you need.

Despite many advances been made in the area of user interfaces over the last decades programming computers to do useful things remains easiest in textual entry. There have been attempts to make GUI's for software creation for a number of purposes, take for example Scratch which is a drag and drop environment that aims to teach kids about programming. This shows there are some niche areas where instructing the computer to do things via a GUI is useful. I do think there's some useful aspects of a GUI in the context of early childhood education, mostly around holding the attention of kids long enough to try some programming and learn some concepts.

And it's this holding of attention that seems to be the main purpose of these GUIs, but in the case of businesses I think the attention sought is from non programming stakeholders rather than those doing the work. In terms of getting productive work done the ergonomics of creating any sort of complicated software in a GUI system is currently poor and in some cases extremely so. As is the case in most (maybe all?) situations in software when the person purchasing the system isn't the one who is going to be using it many frustrations start to sink in as the user experience is almost always worse off for your staff. The more the sales efforts are entirely expended exclusively on procurement the more cautious I am when purchasing.

I'm looking forward to a future where this post ages badly. If there's significant advancements made in a way that GUIs will allow substantially improved productivity for programming computers it will represent progress in the industry. In the interim I'd be very careful with adopting any system that's claiming to be "no code" if that system is planned to be used extensively.

What to do when you hit the limits of "no Code"

Basically you'll have to hire some software staff. I might write about this in the future, in the interim feel free to contact me if you want to hire someone to consult on this process.