Low-code solutions and the problem of citizen developers

As you’re probably already aware, no- or low- code solutions (the terms are essentially synonymous) are rapidly becoming – or perhaps we should say have already become – the next big Thing in IT development. For those not in the know, companies such as OutSystems and Appian are releasing (again, maybe we should say have released) products that purportedly allow users to create full-fledged applications without writing a single line of code (this latter claim isn’t, in fact, universally true – the two main outliers being code to integrate different services and custom UI code – but it is quite commonly the case).

To traditional developers, these products represent an obvious time saving. However, these tools have also given rise to a wave of so-called citizen developers (i.e. business users). Let us state our position plainly: it is excellent when business users develop standalone and non-mission critical applications by themselves. However, when these applications become mission-critical, or are intertwined with other mission-critical applications, things can start to go awry. Usually, the first things to go out the window are compliance and security – things that developers by trade will already be intimately familiar with. As we all know, allowing insecure or non-compliant mission-critical software to be released can be and usually is disastrous (often to the tune of a fat fine and accompanying loss of PR). We could – in fact, we will – draw comparisons to “spreadsheet programming”, which was and is infamously riddled with untested, and consequently non-compliant and insecure, programs. These days, no serious company should entrust mission-critical capabilities to an Excel program written solely by a business user unless appropriate governance is in place. So why are citizen developers being allowed to come back in style, without such governance? In the end, it’s the same devil wearing a different mask.

We’re sympathetic to the plight of business users: they need custom tools to do their job and they need them quickly – more quickly than their in-house developers can produce them, if they even have in-house developers. So, they turn to themselves, and although normally they wouldn’t think to write any code at all, they’re quite comfortable writing a spreadsheet program or – increasingly – a low-code solution. This is fine! They’re not doing anything wrong. In fact, in many ways this is good. The problem is when these solutions become mission-critical without being checked for compliance or security.

So, what’s the solution? Well, in theory, as with spreadsheets, you need some formal governance of citizen developers. However, as far as we know there is nobody offering such a thing. And even if there was it would be probably be more honoured in the breach than the observance. There are two potential problems. Firstly, in all likelihood companies will end up with multiple low/no-code solutions, and any governance initiatives need to span these. From a more detailed perspective, the company’s development team(s) is typically overworked and the process that allows business users to collaborate with developers is either too slow to be of any real value or completely non-existent. The kind of rapid, small-scope development that business users often want when they resort to low-code solutions is very definitely possible in a development environment (at least for non-essential programs) but it requires that the company take an active interest in delivering this sort of development to its employees. The obvious corollary is that it is exactly this kind of development environment which could be replaced by citizen developers. The problem, in our opinion, is that citizen developers, as a rule, do not know where that kind of development stops and where mission-critical development begins. They don’t know what they don’t know: just as security or compliance issues might simply not occur to anyone without the proper training or experience.

Like most methodologies and practices, citizen development is excellent when used correctly: when the proper training is given and the proper boundaries are respected. Ultimately, it seems that citizen developers must accept that, despite the name, they are not developers: they are business users, and they can’t do everything by themselves.