What does no-code or low-code really mean?

Currently, both low-code and no-code tooling receives a lot of attention. One could say they are hyping. You will find hundreds of tools marketing themselves as such, these days. What are they, when do they help? I argue that these tools do not help in the development of complex systems. Why? Simply because 'code' is not the problem there. You need a different paradigm, like provided by Alan - https://alan-platform.com.

While I think there are nice tools in the low-code, no-code category, one thing does not feel right: these tools define themselves by what they are not: code. In general, it has come to stand for: you can change how your software works by using graphical user interface. Sometimes embedded in the application itself, sometimes it is a separate tool with its own look and feel entirely. In addition, a lot of choices have already been made for you: the software architecture, the user interface widget library, etc.

Of course, having choices already made for you, makes the resulting task easier. And to be fair, in 80% of the cases, the end result is the same. And next to that, it is implied that having a GUI to change the behavior of the resulting software will make it easier to change, than having to manipulate code to do that. To the point that citizen developers can do it. And sometimes it is even implied that anyone can do it. Well, if you see how Excel is being misused 'in the wild', I would not encourage that, but ok.

Now, I think this is indeed true for a certain set of use cases: when the function that the software performs is not too complex in itself and the 'citizen' developer has a good mastery of the domain the software is intended for. For instance, by having relevant experience in that business domain. In that case, having a graphical user interface to make changes, has its advantages: it can present options instead of a blinking cursor. It can show specific controls to manipulate specific functions. It is easier to start with. And mind you, there are a lot of applications that fall into this category, so I understand the popularity of these tools / platforms.

However, ask developers of complex systems in current general purpose languages (C, C++, Java, C#, Python, etc) about what makes the software complicated to write and maintain, I am convinced they will not answer it is the code. I have never felt that in my 20 years of experience either. Actually, there is an actual tendency under developers nowadays to replace anything with code. Advantages? Easy to read or glance over, easy to copy / edit quickly, easy to keep track of changes and merge changes multiple developers, conciseness, etc. And there are actually a lot more advantages.

So do not expect not-having-code is going to help us much for complex systems. What I see is code, low-code and no-code platforms basically having the same underlying model. Of a (relational) data model, separate processes (or functions, micro flows, flow charts or whatever they are called) and a gui model that is built using control sets and connected to both that data model and the functions. And next to that, some configurable library to use external (web) services and of course a set of ready made standard connectors to use.

All of what I described is actually not new. All of these elements have already been in use like that since at least 30 years, mostly in the same way. And graphical development environments for manipulating data models, process flows and gui models have been available for a long time as well, going up and down in popularity. Having them integrated in a single GUI to manipulate these models instead of using code is not going to change the fact that these separate models have a problem in and of itself: they mix functional and technical aspects of the application and they have to be maintained separately, while having a lot of overlap. This is the essence of why writing sofware is still so hard, we think.

In Alan, you have one application model describing the functional aspects of the data used, the functions performed and the interaction supported (via a gui or any other interface, for that matter). Interfaces are described in the same way and can seamless be connected to application models. It is a different paradigm altogether and it makes it possible to really only write specifications and have working software (without bugs). Currently, we edit and store these models in text form. For most people this looks like 'code', but not as much, which sort of makes Alan a low-code platform. Later on, we will add other (graphical) ways of manipulating these very same models, making it possible to use Alan in a no-code way. But in both cases very different from other no- and low-code systems. And you will be able to use the manipulation style you prefer.