Why Serious Engineers Should Embrace Low Code

The reaction of many experienced, ‘serious’ engineers to low/no code solutions is as predictable as it is vociferous:

It’s just programming by another name … I prefer to write code than drag and drop … If I can’t write code it will never do exactly what I want … Where are the tests?

Most of what is being expressed are genuine concerns born of real experience. Many of us have been bitten by over-hyped technologies that promise far more than they deliver, leaving us to work around their limitations while our customers look impatiently on, wondering where the hell the promised 10x productivity gains are. If you’re old enough to remember the UI builders and 4GLs of the 1990s (I’m afraid I am!) you’ve seen this all before.

But the truth of low/no code lies somewhere between the hype of the vendors and the scepticism of the engineers, just as it did 10 years ago when the vendors were promoting ‘cloud platforms’.

Because serious engineers were just as sceptical about force.com, heroku.com, Amazon S3 & EC2 in 2010 as they are about low/no code in 2021.

It’s just application service providers by another name … I prefer to configure servers than drag and drop … If I can’t define the architecture it will never do exactly what I want … Where are the tests?

10 years before that it was using browsers and the web as a tool for delivering services and 10 years before that it was using ‘high-level languages’ instead of writing assembly language for anything where performance was important.

Step back a little from the arguments and consider for a minute that low/no code is trying to achieve exactly what cloud platform development was trying to achieve a decade before: focus on the things that make your solution unique and valuable to your users, not the things that make it the same as every other software service out there. Where as cloud platforms were taking away the performance, scalability, availability and security issues and letting developers focus on application code, low/no code takes away a lot of the boilerplate of data transaction handling, event handling, workflow and UI aspects of the application.

If raising the level of abstraction can work for infrastructure, it can work for applications. Of course there is a lot of snake oil out there that will further entrench sceptical positions but there is some good stuff too. Here’s what I look for in a good low/no code solution:

• Fitness to problem type. The higher the level of abstraction, the more biased to a view of the world it typically is. So don’t try and use the Salesforce Lightning Platform for high-volume real-time data handling and don’t use Airtable for mobile apps. But for MIS and spreadsheet replacement type problems, fill your boots.
• Ability to incrementally refine the low/no code solution. What got a lot of the UI builders a bad rep in the ’90s was that it was all fine while what you needed could be built in the builder and then rapidly fell apart as soon as you needed change some aspect of UI behaviour. It was all or nothing: either you used the builder exclusively to build your UI or your wrote it from scratch. The best low/no code solutions allow you to replace and refine the behaviour of individual elements in isolation; you can have a solution that is 80% point and click config and 20% full custom code or 20% config and 80% code if your solution so demands it.
• Degree of integration with other technologies. Another issue with the 90s/00s generation of low code type solutions was they were often a completely closed shop. The best of today’s tools will happily hand off data and events to AWS and GCP services or integrate with your existing data stores and event streams.
• Ability to work with config like code. Beware the low/no code solution where you can’t put all that config under source control, merge changes together, run builds and deploy an assembly of config and custom code as an atomic unit. And it should support automated tests!

Where low/no code can really win is when it takes away the tedious and boring but still leaves us in charge of the innovative and exciting, whatever that means in your problem domain. Consider the elegance of

squares = [x*x for x in range(100)]

versus the equivalent in 6502 assembly language. Okay, so calculating squares of numbers up to 99 is hardly innovative or exciting but the focus is very much the calculation, not manipulation of memory, function pointers and numbers bigger than an 8-bit processor can handle. To a 6502 hacker, a Python list comprehension looks a lot like low code but does anyone still argue that the Python somehow isn’t ‘serious’, that this isn’t ‘real code’?

Good engineers search out and use (or invent) the best tools for the job. Low/no code is another powerful tool in the box, even if you don’t like dragging and dropping.