DEV Community

Cover image for Low-Code and Software Quality
Thomas Hansen
Thomas Hansen

Posted on • Originally published at

Low-Code and Software Quality

There exists a lot of misconceptions about Low-Code. Some of the objections I have heard is that you can only use Low-Code for smaller projects, you will get stuck as you try to do some things, forcing you to scrap your entire codebase later - Or that Low-Code produces inferior quality. In this article I want to write about Low-Code and software quality specifically.

I can only speak about our own Low-Code tools obviously, and that some Low-Code tools might produce inferior quality I have no doubts about. However our Low-Code framework primarily produces code by reading meta data from the database. This implies that most of your codebase is machine generated.

Humans do mistakes, the machine does not

The quality argument really condenses down to the above. The machine will do exactly what you ask of it. If you tell it to multiply 2345 by 8765, it will do just that - Without mistakes. While a human being might do a mistake, maybe due to thinking about which coffee to get during lunch, or because it has grown tired after watching the computer screen for 16 consecutive hours.

Another fact is that most Low-Code tools will reuse the same code snippet multiple times, the same way a snippet of code is being reused multiple times from a library. This allows the producers of said snippet to spend much more time weeding out bugs in that particular snippet of code. If you have 3 months to finish a project, and somebody else have written a piece of code for that project that they can spend their entire lives optimising, it doesn't take a rocket scientist to understand that probably the library snippet has fewer bugs than your own code. It's got little to do with how good of a coder the library writer is or not compared to you, it's simply a matter of the amount of mental energy applied to the problem.

A third fact is that with Low-Code frameworks, the same code is being used and shared by hundreds and sometimes thousands of different companies. So the price tag to maintain the code, is also shared. Regardless of how much money your company has, it does not have infinite resources to maintain a small snippet of code that's only used in one project and consists of 30 lines of code. A Low-Code framework has much more time and resources to spend on that same snippet of code. An example from our own tools is how we have spent hundreds of hours fixing bugs and making our SSO module better. If you're creating authentication for a single app, you're lucky if you've got a couple of weeks to implement it, weed out bugs, and make sure it's secure. We've spent hundreds of hours fixing bugs in our SSO module, and it's used in hundreds of projects. Internally we're using it in dozens of projects. And as we use it, and we find bugs, we fix these bugs, and continue.

All in all, manually writing code as a human being on a per project basis, cannot compete against Low-Code on quality. It's impossible even in theory. When it comes to Low-Code and software quality, Low-Code almost always produces higher quality software, and the reasons are arguably found in the slogan for Aista, which is as follows ...

Where the Machine Creates the Code

The human being simply cannot compete!

Top comments (4)

aarone4 profile image
Aaron Reese

The problem with lo code is not necessarily the platform and all the points you made are valid. The issue is the target audience. Power Users and Citizen developers are a fallacy and giving them the ability to create solutions without oversight from IT is asking for trouble.
Typically these solutions have:
No cost justification
No business analysis
No impact assessment
Assume perfect data
No defensive programming
No error logging
No source code control
No tests
No deployment pipeline
No documentation

These are all seen by end users (who have to wait months for IT to deliver solutions) as impediments to getting what they need but are fundamental to the good governance and 'profession' of software developer

polterguy profile image
Thomas Hansen

These are all valid points, but 90% of them are only valid for No-Code. Low-Code has its range of problems, but not the ones you mention here. Low-Code requires a developer. The automatically generated code can easily be versioned in Git for instance, and such projects have PMs usually and project goals and oversight. They're simply 10x better on all parameters. This is the only difference really ...

wyattdave profile image
david wyatt

I think low code is just the next level, as we moved from machine to low-level to high-level, we are now moving to LowCode (and eventually no code). We don't lose features, we standardized (any missing features are more to do with either the platform or immaturity). As you said the benefits of that standardized code is immense (it's why npm is so popular).
As with all coding languages, Dev's can be triable, and dismissive of other languages/frameworks, LowCode is often just the easy target.

polterguy profile image
Thomas Hansen

Smart comment. I've been around long enough to remember Motorola 6800, and creating ASM code for it. Today such an approach would be madness. Low-Code is simply the next step on the ladder. 20 years ago garbage collectors were considered "garbage" by anyone serious. Today I don't know a single dev not using some GC ...