How I learned to stop worrying and love low-code

Some of the most fervent opposition to low (and, even more so, no) code development comes from the people who would, in principle, benefit from it the most: developers. While there are valid reasons to be wary of low code (for example, that citizen developers aren’t usually qualified to judge whether an application is secure and/or compliant), the majority of these concerns have been addressed by the technology available. My suspicion is that many – if not most – issues that developers have with low code stem from the fact that most programmers like to, well, program. Low code and particularly no code suggest a dramatic reduction in the amount of code that needs to be written, and to someone who likes to code, this is anathema.

I’ve written this blog to discuss my feelings on the matter, both as an industry analyst and as a (former) software developer. There are two important points I’d like to get across: 1) low code and no code don’t remove as much code as you might think, or at least not as much interesting code; and 2) software development isn’t really about code, anyway.

In regards to point 1), the reality is that an application needs code somewhere, and if a no code tool really doesn’t allow for any coding whatsoever, it will inherently be limited to the functionality it provides out of the box. In fact, this is rarely the case. Most low code and no code tools have a component driven structure where developers still write code, they just do so in encapsulated pieces that can be assembled into an application at a later date.

The upshot here is that, while you will literally need to write less code when using such a tool, you will still have to write your application’s actual functionality, i.e. the code that is meaningful, interesting, and – most importantly – enjoyable to write. On the other hand, you won’t have to write code that either duplicates existing functionality or pipes functionality together. Such code is usually trivial and rarely interesting, so from a developer’s perspective this should be no big loss. At the end of the day, the amount of time spent writing code that is interesting to write should remain the same. Low code just automates the rest.

(As a side note, this component driven structure – wherein each capability is encapsulated and later assembled into a working app – should be familiar: it is very similar to a microservices architecture, which many developers use and, in some cases, even like).

Point 2) is more philosophical. My personal experience leads me to believe that the basic act of programming, in all but the most radically obfuscated languages – see: COW, Brainfuck, Whitespace – is not terribly difficult, and the vast majority of code that gets written is, likewise, pretty easy (if sometimes laborious) to actually write. My supposition is that the value of a skilled developer comes not from the code they write per se, but from the design and the architecture of that code within a wider context. In effect, the skill – and, in my opinion, the fun – of development comes from thinking through the logic and maximising the efficacy of the solution rather than the actual process of coding.

For a developer, then, the value of a low code product comes from the fact that it cleanly separates coding from architecture: each component may need to be coded in and of itself, but the act of connecting those components and assembling them into an app doesn’t require any coding at all. Thus, skilled developers are free to focus on the parts of development with which they provide the most value: architecting and design. That doesn’t mean they can’t still write code – they probably should, all things considered – but that they don’t need to think in terms of code when what they are really doing is architectural. Essentially, this is a separation of concerns: coding on the one hand, architecting and design on the other. My point boils down to the observation that developer brainpower is more often spent on the latter than the former (although, of course, there is always debugging – but that’s a separate topic).

In summation, my message to developers is that low code is not something to be feared. Like a good IDE, it will let you focus on the parts of development that you most care about, while eliminating the parts that you don’t.