EnglishCTO-for-hire (through Freeman Clarke) Alex Hudson recently wrote an article about what he terms “The ‘No Code’ Delusion”: That so-called no-code and low-code tools will replace bespoke business software development entirely, no trained software developers required anymore.
In a nutshell, it’s the old pipe dream of just having to write a specification (in this case a visual one) and having the actual code write itself, the fallacy here of course being that the code is the final product rather than the specification for generating that product (hint: There’s a reason why production environments are named that way …).
In his opinion, low-code tools fall short on two counts – which in my opinion is less a failure on their part but rather as to how they’re commonly perceived:
- They allow you to fairly easily achieve 80% of what you set out to do but the remaining 20% become immensely difficult or require elaborate and cumbersome work-arounds. As usual, the Pareto principle applies.
- Software created by low-code tools is still software but in contrast to actual code that sits in your source code repository it usually resides on some sort if third-party platform with often no obvious manner of tracking and controlling changes. Transitioning from such a third-party platform to your own system and machines – should the need arise – can also become a major, non-trivial problem, even if done gradually.
Nevertheless, I think no-code and low-code platforms are an enormously useful innovation in that they allow you to delegate stuff that doesn’t work as a key differentiator for you, i.e. they allow you to focus on your core domain while having a tool take care of routine processes (i.e. supporting and e generic domains). They’re also tremendously conducive for quickly prototyping a proposed solution.
They are effectively an extension of my mantra of using boring solutions and outsourcing repetitive work to existing tools so you can work on what’s truly important.