After having been staffed for months on a project involving a low-code platform, without knowing it at beginning, I took time to read what specialist newspapers or colleagues’ blogs would say about it. And I was quite surprised by the perception gap !

Specialist newspaper are quite confident in the opportunity opened up by No-Code/Low-Code solutions. When you surf the internet, you read a lot of positive promises. These platforms would make the time-to-market of product shorter. They would allow people with absolutely no technical baggage to produce software reliable and easy to be maintained by non-developers. These non-developers could be so random, than the poetical term “citizen developer” was coined to describe them. Some source do not hesitate to prophesy a low-code winter for those who dare to resist the low-code wave. Rarely you come across warnings like “it is good for prototyping, but limits are quickly reached”, but it is often followed with a reassurance like “if you choose wisely your low-code platform, which meets your project requirements, you will not meet this problem”.

On the other end, developers in their majority are much more skeptical. Old-time developers are much more into a sense of “déjà vu”. Some other suggested that it might be useful to speed things in a tiny number of situation, without really disrupting anything.

I proposed you to follow me into this question : “Are No-Code/Low-Code solutions, really solutions to business problems ?”

In the beginning, was the turing completeness

Yeah ! Let’s scare the innocent non technician people passing by with complicated terms !
Do not worry, stay calm ! You are certainly able to understand, do not underestimate yourself nor overestimate the topic. Furthermore, it is simple to popularize.

Turing completeness is the ability for a system of instructions to simulate a Turing machine. A programming language that is Turing complete is theoretically capable of expressing all tasks accomplishable by computers; nearly all programming languages are Turing complete if the limitations of finite memory are ignored.

https://en.wikipedia.org/wiki/Turing_machine

Let’s say that a famous mathematician in the last century imagined a machine able to describe all the fundamental operations needed to proceed all possible computations, or almost. Such a machine, if it exists would have a wide open world of possibility to proceed information.
At first purely theoretical (Alan Turing imagined it before the first electronic Turing-Complete computer), it then became reality. Any formal system such as programming language or electronic cardboards are quoted as “Turing Complete” if they give an range of possibility comparable to Turing Machine. This expressivity is used by developers to make software solutions through programming language such as C#, Rust, C++, etc, but also by electronic engineers.

But, is a machine, allowing you to do anything you want, really useful ?

Then, the Lord shall be more specific

A famous quotation says :

Art lives from constraints and dies from freedom.

attributed to Leonardo Da Vinci or Michelangelo depending on the sources

The sentence could also be “Engineering comes from constraints”, because as stated in Discussion of the method :

The engineering method is the use of heuristics to cause the best change in a poorly understood situation within the available resources

Billy Vaughn KOEN — Discussion of the method

On a daily basis, nobody could efficiently use a machine doing absolutely everything without discernment. What is needed is the most possible straightforward procedure, users can track down to speed things up. Within this goal, developers debated and generated a lot of concepts, design patterns and tools to constraint the work of developer toward the best possible practises. These best practises made programming faster, more reliable, and easier to maintain.

The vocation of software engineers is to tame complexity, from the staggering space of possibility offered by Turing Machines to the narrower space of needed solution, from the open-ended to the specificity. Schematically, the same way a funnel becomes tighter.

Software are therefore designed to match as perfectly as possible the needs of final users. But the way you meet the customers’ requirements is totally different depending on the business context and the aim.

And the Lord asked “Does anybody want my software ?”

At the beginning of Computer Industry, hardware was a precious resource. It took a lot of precious metal and competences to be built, and a lot of space to be stored. Computer were most of the time bought to do a particular job. This particular job did not necessary imply a human in the process, but simply replace it. There was consequently no need to care about “Is programming easy ?”. You hired a programmer once, who programmed it once and for all, or rarely, and the machine went to production.
This “expensive hardware/rarely reprogrammed” paradigm persists in many context such as embedded devices, medical devices, IT departments, and so on. In these contexts, any minor inefficiencies can have huge consequences. This technical paradigm is often referred to as “batch programming” or “system programming“.
Programming languages such as ASM, Rust, C, C++, Fortran and some others fall in this category and materialize the lowest possible level of programming an engineer might meet in his career. It also represents the most complicated and fundamental level of competence and knowledge for a programmer.

At the other end of the spectrum, you have the “interactive computing” (IC).
To make it roughly summarized : in this technical paradigm, the computer is like the calculator you had for maths in high school. You specified in a clear formalism a problem to your calculator, then got the result, and specified another problem to your calculator, and so on. Command-Line Interface is the very basic example of this. Generation and generation of workers in offices had to interact with very expensive and specific computers only through this kind of interface. They had to write instructions resembling more witch’s spell than anything else.
But in such paradigm, coding is not only about matching final user needs, and it also implies matching the psychology of the final user. The user has an emotional experience with the system. If it is painful to use, the user will avoid using it.

Let’s get back to our previous question : is a machine, allowing you to do anything you want, really useful ?
Talking about a machine doing everything “even making the coffee”, is a famous joke meme. A machine doing too numerous thing is often seen as unreliable. Consumers often tend to prefer objects with a single purpose. It is the most reassuring choice. Nevertheless, lot of multipurpose objects earned their market share. Swiss knives, kitchen aids, or smartphones have the benediction of consumers. Smartphones are a very interesting case, because nowadays we all use smartphones, which substituted lot of other devices such as walkman, phones, means of payment, and the list goes on.
So why did it work for smartphones ? Because the user of a solution needs to identify with it. And users perfectly identify themselves with these tools. Smartphones or swiss knives are made to be convenient for final users.

If you want the users to identify with a software, this implies interfacing human with something convenient.

And the Lord created the “Low-Code”

According to most sources on Google, the term “Low-Code”, or its complete name “Low-Code Development Platform” (LCDP) was coined by an advisory company named Forrester in the 2010s. But if this term was coined recently, the reality it describes is absolutely not new.

Low-code is a software development approach that requires little to no coding to build applications and processes. Instead of using complex programming languages, you can employ visual interfaces with basic logic and drag-and-drop capabilities in a low code development platform.

https://kissflow.com/low-code/low-code-overview/

Firstly, “complex programming language” is an elusive and non specific description. What complex actually means ? Is Python a complex or a simple programming language ?
Secondly, to make interactive languages easy to appropriate, it was important to make them easier and easier, decade after decade. Computer scientists were really aware of it from the 1950s. This is why the very first interactive language LISP was introduced in 1958, and the first program making graphical interaction possible was Sketchpad in 1963.
Thirdly, the term “low-code” is quite confusing. The normally used terms are “low-level programming language” and “high-level programming language”. “Low-level” refers to little or no abstraction from a computer’s instruction set architecture, and “high-level” on the contrary refers to a strong abstraction from the computer technical details. This is certainly this last category the term “low-code” targets.

And unsurprisingly, most of the novelties of the software industry these 40 last years are oriented toward languages with high-level of abstraction and as interactive as possible : Python, C#, Java, Perl, PHP, … all those languages pay an abstraction penalty to make work of the programmer easier. It is even possible to make a Domain-Specific Language, which means programming languages focused on a small and restricted business domain.
On top of that, tools surrounding the activity of programming like frameworks, tests, continuous integration, continuous deployment, type systems, or summed up Integrated Development Environment (IDE), improved a lot.
But does all this new setup make programming more convenient ? Of course it does ! But this convenience comes with a cost : apprenticeship. As productive these tools and concepts might be, they require to hold on a minute and to learn them. And here comes the gap most of people are afraid to cross : programing is about learning. You learn a programing language, then about the libraries and frameworks around it, then about the tool to debug what you missed to achieve, then about the tool to accelerate delivery, then about the tool to make software quality better, etc.

To implement the pledge of LCDP, to make programming the easiest possible, these platforms have no other option than squeezing the problem space as much as possible. The less possibility left to the user, the least problems you have. “Low-Code” will have to be a domain-specific language, adapted to a very specific context, with a specific integrated environment, and will give access only to a little number of possible features. If you need to extend the feature space of your low-code platform, unsurprisingly, you will need to hire competent developers.

And the Lord created the “No-Code”

But software users are rarely software developers. They are office employees, engineers, shipyard workers, traffic controller, game players … These people need to get the job done, as quickly as possible. Learning witches’ spells, is not always perceived as the most straightforward and user-friendly way to have it done. Software engineers conceived along history new human-machine interfaces. There is a lot of different possible user interface according to context. The most commonly used and preferred by users, is graphical user interface (GUI), simply because for most of people the preferred sense is the vision. Unsurprisingly, GUIs are like everywhere ! Video games, spreadsheets, music composition, social networks, …

But this would be short argumentum to say “No-Code is simply not having interactive coding and software without interactive coding is not new”. But actually, many articles we can find on internet are really confused about what “no-code” refers to. I found several articles pointing WordPress as being a “no-code” solution, which is completely meaningless ! If WordPress is a a “no-code” solution, so are Outlook or GeoGebra. Sadly, I was unable to find the original source of the term “No-Code”. I do not know who coined it in the first place. But the true complete name is “No-code development platforms” (NCDP). And the message in the name is clear : it is about making software without writing code, but by using another interface, mostly GUI with boxes, arrows, etc. And this is not new neither ! But in the past, it was called differently.

Let’s remind the reader with a very simple fact. When developers try to make an executable program, they write a detailed specification, and give it to a software. This software is called a compiler (or an interpreter in some case). To say so, we have software making another software. And like with any software, interfacing with a compiler can be done in a lot of manner as we stated earlier in the text. The most common one is by using a programming language, but already early in history some engineers imagined a way to give the detailed specification in a visual way, with graphics, with the hope to make programming more accessible to a certain class of worker with no special qualification. And here comes the true historical name of NCDP. Before this new name was coined, we referred to it as “Visual programming system” (VPS).
And the list of such system already designed in the past is long, very very long. And they are not coming from the 2000s or sooner. At the rising of oriented-object programming in the 1980s, this was already common rhetoric to say that programmers will only need to draw enoughly detailed schemes to generate an executable. The same rhetoric emerged when Unified Modeling Language was introduced in the 1990s. In the end, have VPSs won a landslide victory within the software engineering market ?
No. VPSs, and therefore NCDP have sticked to a niche role in the software industry.
But why ? In the first place it sounds a great idea. Why would be visual programming not more “user-friendly” and popular than classical text-based interface ?

And the Lord cried out “Why does not anybody still want my software?”

Any tech company will tell you the same story : user adoption is a real problematic. The qualities a technical solution must gather to become a rockstar are very numerous : it must match a real and urgent need, the benefice must be understood by users, it must be convenient to use, difficulties in use should be easy to tackle down autonomously by final user, … Compilers, VPSs, NCDPs, or LCDPs are softwares like any others, and are bound to the same constraints to reach market adoption.
So, what VPSs might have missed to be sticked to a niche role ? The main answer is productivity. Clients have always asked developers to deal with the shortest deadline possible, and developers are like any other human a bit lazy and motivated to finish work as fast as possible. Therefore all incentives have been inline to go to the quickest solution. Visual programming seems to make the things more convenient to read, but certainly not to write. Anybody who already dealt with UML diagrams know how frustrating it might be to build a simple but nevertheless meaningful UML class diagram.
The main feedback of the VPS through decades has always been : this is far easier and faster to write source-code than to draw it. For this reason, I challenge you to find a developer programming with VPS and UML. But this is perfectly usual to find development teams extracting UML from their source-code to feed the documentation.

And the Lord finally understood the core problem

Some VPSs have been designed to address the smallest problem space possible, to make the drawing system really easy and straightforward.
In another life I was electrician, and I had to program automata relying on primitive input-output combinations. We were given a simple graphical interface, specifically designed to remind the electricians of the electrical diagrams used in the profession. For the need we had, it got the job done. But it took us a day to learn the documentation to configure maybe 10 or 20 combination rules. I never heard of these automata again then. I and my colleagues contributed maybe for 1% or far less of the cumulated work time necessary to code these rules. The remaining 99% or far more had been the contribution of the developers’ team involved in designing this quite user-friendly solution.
And this is another irony of these software solutions aiming to avoid need for authentic and hardcore developers : these solutions need developers in the first place to exist. The tactic is easy to understand and is the same for absolutely any software in the world : this always relies on a lever effect. A partial software solution is brought to a problem space by professional developers. The final concrete implementation is left in the hands of unknown but for sure unskilled workers. If the unskilled workers achieved to satisfy the final need, then time of skilled worker was saved and the global productivity of the value chain was leveled up. This is only possible if we can identify genericity in problem space. But is software development a generic problem ?
In some sense, of course ! Even if developers do not all use the same tools, the fundamental concepts are the same. But the way they are implemented differe and it requires time and experience to be good at mastering them. If a developer does not master deep knowledge, he is alienated by its tools. And this was my case with the automata and their electric-diagram-like VPS.
No junior developer is sufficiently taught and trained to have these deep skills when entering the labor market. It takes months and months with a good senior Sensei, or years if left alone in the dark, to turn a promising apprentice into a solid senior developer, never mind the “citizen developer” left alone with an easy-going LCDP or NCDP platform.

But the struggle is real ! Skilled developer shortage is an ongoing problem for years and years. The pressing needs for software solutions push actors to find quickly new solutions. And LCDPs and NCDPs, or to be more historical ICs and VPSs, find here a new possible commercial outlets. The same tactic, specifically applied to software production, is proposed as the ultimate loophole to developer shortage. This tactical pattern has become the Holy Grail of software industry for decades. But as the veritable Holy Grail, nobody is sure to have seen it already, and its existence is doubtful. This Holy Grail has been historically called “Rapid Application Development Tool” (RADT). When we tell you that these things are absolutely not new.

And the Lord saw the obstacle denial

Any tool that lets a non-programmer build executable programs will eventually become sufficiently complicated that the user is effectively a programmer.

Mathias VERRAES, Twitter, 2018/09/18

The french developer Mathias Verraes stated it in a tweet in 2018, which became famous as the Verraes Hypothesis, or the Verraes Theorem, and it pretty sums it up.

The fundamental question is “Who is responsible and deserving for added value ?”. Commercial and remuneration discussions are always about what is the fair share of added value. In the case of any software (including LCDP and NCDP), sharing of added value works like communicating vessels between final users and developers. The more developers add value, the more they earn, and the less the final user can earn, but the more the final user can save time in his task. The more final users add value, the less developers deserve to earn. But the more final users hold the responsibility for added value, the more the tool must have achievable features, the most developers must spend time on it, and the most final users must be skilled worker. This is a endless and vicious circle !

And this is where LCDP and NCDP are quite inconsistent. They claim to give a non-developer the ability to make softwares which will bring strong added value to final users, but to make the features truly achievable by a non-developer, they have talented developers work on a solution space narrower than classic programming languages actually have. When the customer (who is rarely the non-developer working with the tool) need a specific feature for his business, and this feature is not achievable through the LCDP/NCDP chosen, here happens the tragedy. The customer only can :

• Submit a request to the platform provider and wait for the development of the feature in a unpredictable time. Maybe it will never happen.
• Ask their non-developer workers to twist the solution as much as necessary to make the feature magically emerge, if it is actually possible. The non-developer will maybe lose weeks and weeks to succeed, or he will never.

• Start from scratch with a new platform provider who pretends to have a more complete range of feature including the one expected by the decision-maker. This will force the non-developer to learn everything again, and become a more skilled mild-developer.
• or… start from scratch with a real development team working on a proven and time-tested set of tools.

In the end, these convenient solutions trying to avoid you to hire competent developers, push your non-developer to become a new developer specifically skilled for the development platform you had chosen.

Furthermore, your newly skilled worker who became software developer at his expense, does not necessarily see it well. He may not want it in the first place. Numerous people are perfectly able to become software developers, but do not want to become one of them. The range of reasons is particularly wide and very personal. Some do not like to stay a long time in front of a computer. Some other are simply uncomfortable with the activity of programing. Some consider it is far too easy for them and not a worthy challenge to them. Some are quite good at programming but absolutely lost when comes up the time to structure the information system, because they lack of ability to analyze and think systemically. Software development is a particular scope. Lot of software engineers in the past stated that this required a particular set of mind. A decision-maker can really make its employees uncomfortable and provoke a “we don’t want to code” revolt among them. This revolt will lead the decision-maker to hire a skilled developer to struggle with the RADT.

As I repeat all the time :

You are never emphasising the need analysis enough.

Me

You can get easily lost in complication when you are not focusing enough on the true fundamental need. The need is not “I need an easy development platform”, the need is not “I need more features”, the need above all is “I need competitive advantages to win market shares”.
The solution is not a “easy development platform”, because these solutions are purely generic and do not bring any competitive advantage. Do you really think Netflix, Amazon or Facebook buy SAP licenses and then try to put by forceps their information process in it ? Nope, they absolutely do not do that. We then get back to the true solution. A solution we all know. A solution I already recalled in this text. We must have more competent developers. But this solution requires another investment. It requires to hire juniors, to support them, to put seniors in front of them to train them, etc. This true but medium to long term solution is seen as insuperable by decision-makers.

This, is the obstacle all this “low-code”/”no-code” movement pretends to allow you to deny. But like in athleticism or horsemanship, obstacle denial is eliminatory, soon or late.

But if you think it through, calmly, if you are ready to pay quite a lot of money for “easy development platform” and push your collaborators to become some kind of developer, why you would not directly pay for the training of new developers ? Actually there is good reasons explaining why the raising of new developer is quite complicated, and I already made an article about it, but decision-makers should really reconsider hiring and training developers.

Conclusion

So, are No-Code/Low-Code solutions, really solutions to business problems ? Probably not.

• There is no cheat code to make valuable software easier and cheaper.
• Do not use rapid application development, low-code, no-code for anything else but prototyping.
• Generic on-shelf solutions are not no-code solutions, but simply softwares. They may be useful, but they are not magically able to do anything, but just to match the generic problems you and others might have. Pick them wisely.
• Software industry is prone to marketing bullshit. Decision-makers should be very wary when reading glowing articles about novelties. True disruptive novelty in the software industry has become rare. Novelty is often mostly rebranding of solution already seen in the past. Rebranding has often the purpose to subvert the “Search engine optimization” (SEO) to avoid decision-makers to google an ancient term with lot of scornful comments. Be aware !