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?

Image for post
Image for post

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.

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.

Technologist; CTO; Product Owner; Music Lover; Film Fanatic; Dendrophile.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store