To Code or Not To Code. My take on Low-Code/No-Code systems

Low code systems were all the rage a few years back. I forget which came first, low-code or no-code. One is an iteration over the other, talking about basically the same thing, but coined as a new term to sell you a old-new product to solve the same pain: development work takes time and skilled labor.

Low code systems are not a new idea. We’ve been inventing abstraction layers over previous layers of code for many many years. We invented binary systems decades ago, then assembly code, then C or something like it, then Java, and so on. Low-code was supposed to be the next iteration; however, mostly low-code platforms went about it trying to reinvent the wheel. They created systems that lived outside of the realm of software engineering, that were ruled by their own logic, and their own standards. That, to no surprise, is a barrier for developing enterprise-level software. While these tools are indeed powerful and capable, how do you bridge the gap between them and the rest of the world? After all, we’ve built mainframe systems over 30 years ago and many of them are still functioning. How are we to merge both worlds? That, and many other challenges were and are still hunting the low-code world.

Reinventing the wheel

Here’s where I think most low-code systems got it wrong: They reinvented the wheel. Or they tried to. And the wheel sucked. Mostly. Why? Because inventing a system that lives alongside other software, but isn’t quite ruled by the rules of software engineering is tough. We’ve been building software for many years now, and we’ve had a bunch of learning over the years, and systems have been built to deal with our pain, as well as processes have been established for building quality code. This process is still debated today, and every company out there is trying to stay in the know and apply and modify the “best practices” to their needs. I think Agile is over 20 years old now and there are still companies dedicated to teaching it and applying it. The field of software engineering, while relatively new, has had a number of learnings. Most of those learnings were sacrificed at the shrine of the Low-Code gods. The problem lies in that those learnings are valuable for a reason.

I won’t list them in any particular order, but here are a few that were sacrificed:

1. Version Control

We’ve had two or three major/decent version control systems I can name. SVN, GIT, Mercurial. I don’t recall using mercurial, I think I’m aware of it because a software I used to run in the past installed it by default. Here’s the thing with version control: it is essential to building good code. Nobody builds good code without version control. Why build a new system? Well, we build new systems all the time. We tinker with ideas and try things out. Here’s the problem. Only the good ideas get adopted. We’ve all built bad ideas before. They get left behind. If you are going to build a new version control system, it has to be superior to the old system, either in cost, in performance, or in features, and not just better, it has to be superior, so that it may be adopted. SVN got dropped for Git due to performance. Git’s cost is $0, so you can’t beat that. Thus you need to beat GIT on features, and building a visual system for version control that’s handling visual elements is no easy feat. No wonder these systems couldn’t do it. This task by itself is a large one. Additionally, it isn’t just building the tool itself, it is building the ecosystem. We have a large amount of tooling that wraps around GIT. We put everything in GIT, first code, then infrastructure, then configuration. We even put data under GIT’s purview. We have visual tools for comparing changes. We have processes that go around how code is versioned. We have branching strategies and who knows what else. And we have them for a reason. We don’t build processes just because we like them.

2. Processes

I just said above nobody likes building processes for the sake of building processes, although a few bureaucrats might argue that. In modern software development, one of the key mantras is “move fast and break things”. To do so, you must have some processes in place, at the very least some testing, and some code reviews. Both today are tied to GIT in some shape or form. Code reviews happen as part of merge requests, and automated testing happens as part of pushing code into the system. Let’s focus on the review part for now. However good your low-code or no-code functionality is, I’m sure someone needs to review it. For that you need to track changes, and those changes need to be easily understood. That’s all fine when you are just making one tiny change, but even for the best engineers sometimes one tiny change becomes a lot of changes. How do you track that? How do you verify that’s OK? How do you merge that?

As said above, version control is not that easy when doing visual systems. Part of the tooling we engineers have built over the years is comprised of linters (that tell us when we’ve messed up), compilers (that really tell us when we’ve messed up), and all sort of functionality in our IDEs to help us comprehend who’s calling what and why, and what arguments are expected or passed. All that clarity is trivial in small systems, but essential in large applications, even if you are building microservices. “Code reviews”, thus, become also difficult in this kind of system. Regardless of their name, code is there, and it needs managing and reviewing.

3. Testing

I haven’t tried one low-code system yet where testing is easy. I’ve tried a few very decent low-code solutions, but testing has always been an after-thought. You can’t build speed and quality without testing. Testing is front and center of any good software operation. Until that’s done right, you just can’t trust the system.

4. Scale

If you are building something small, a proof of concept, scale is no concern; however, if you are going to be building something that’s going to be producing revenue by spending money such as advertising through SEM campaigns, you need to be able to scale. You can and should try ideas however it is you can build them and test them the fastest, and here low-code solutions may be a good approach; however, if you want to replace code-based development with low-code solutions and go all-in, you need to be able to scale. Until recent one of the top two low-code solutions out there was still server based without a container-based approach. What’s more, you had to submit a ticket to someone for their team to scale servers up. Talk about old school. If you want to build large systems, this approach is unnacceptable.

5. Monitoring

How do you know your systems are up? How do you monitor them? How do you get alerted when things go wrong? Is that monitoring and visibility built-in and standardized? Is it compatible with the monitoring ecosystem, or is it stand-alone and part of your solution? Do you have to reinvent that wheel too? If so, most likely you’ll come up with an inferior solution. Without great monitoring you can’t build great systems. If you want to build a mediocre system that’s OK, but if you want to be best-in-class, top notch monitoring/visibility is a must. I felt in love with Kibana and the ELK stack many years ago. That’s the starting point for me. Anything inferior to that standard is not good enough. I think a lot of progress must be done in this area.

Where things can go right

Abtraction, as I mentioned, can be desirable. However, no-code solutions for the most part fell flat. Some of them have even abandoned the market, such as Amazon’s Honeycode. That’s not to say the idea is wrong. The idea can be quite right. Wordpress has built some arguably decent low-code solutions, perhaps unintentionally. Wix is a business thriving on the idea that building websites shouldn’t require knowing code. They got something right. Shopify also has some similar idea in mind. Selling should be simple. They are working on that. You can do a little bit of code there, but you don’t need to be a code in order to sell. That’s where low-code solutions can bring a lot of benefits: simplifying complex operations into simpler constructs. I’m all for that, so long as it can be done in a controlled fashion and so long as we can open the hood and take a look under the covers when we need to change a spark plug or two.

Conclusion

Some abstraction is great and desirable indeed. Where some low-code solutions got it wrong was trying to build and end-all-be-all solution to replace software as we know it and build it today. This is a really large undertaking. If you are going to embark on it, don’t ignore the fundamentals of building great software. Also, great software is built in teams. Collaboration is key, and the processes and workflows that exist today must be incorporated in some way or another, ideally without adding more complexity to the system. Solutions that ignore the fundamentals are destined to be niched. This whole idea is now behind and we are on to the next big thing. I don’t think the idea is a bad one, and I’m sure they’ll resurface again when we run out of steam with the next big thing and consultants run out of ideas of what to do with LLMs. Until then, I do hope these companies work on the fundamentals a bit and improve their offering, after all, testing and monitoring are a given in any good development system. Who knows how we’ll build software tomorrow, but I’m sure we’ll still want to make sure the systems are running fine, and that we don’t break it when we make changes.