Are Citizen Developers Dangerous?
The possibilities of citizen development are ever increasing. The Power Platform and Flow (in the Microsoft ecosystem) are becoming increasingly ubiquitous and we are starting to see more and more exotic use of the capabilities that far extend (in my view) beyond the intent of the technology.
Citizen Developers make me nervous. There. I said it. In my view we’re in a race to the first serious media explosion over a ‘leak’ caused by home-brew applications written by sales folks or accountants.
Let’s be clear. I get the benefits of the model: agility, velocity, delegation, collaboration, democratisation, but these all need to be weighed against the risks of development without discipline.
I saw a post recently from my friend Serge Luca (here for convenience) entitled ‘Create a Flow that finds your Flows’ the first paragraph of the post I will quote here for posterity:
I don’t know how it works for you, but it looks like I cannot always easily find flows I did create weeks before. They are stored in many environments and I give them sometimes very weird names.
Wow. A Flow to find Flows? Madness. An experienced software guy sipping at the sweet nectar of being able to develop and deploy too easily? Probably.
Some kind of crazy lack of governance Inception going on here.
Let’s be clear here. I like Serge and I admire his work and community effort and this post is in no way a poke at him – but this paragraph shows, in a few words, the reason that citizen developers make me nervous. Of course, I recognise the intent of the post – Serge was showing a (clever) way to use Flow to manage the chaos he knows he is creating – he is an awesome educator and wanted to share something that he finds useful and (most likely) others also will. For Serge, this is fine – but it is a stark reminder to mere mortals using Flow (and other NoCode/LowCode tools) of the reality of the hailstorm that can be created without appropriate controls.
Citizen Developer tools enable the removal of the one thing that software engineers learn early on – discipline.
Software engineers (by and large, there are always exceptions) learn to understand impact, they know to respect consequence, they understand the value of naming convention (and comments), and they understand the importance of vigorous testing. Good software engineers learn to write code not for now but for 12 months time when somebody else will be responsible for maintenance of what has been built.
I always encourage my engineers to ‘write code for yourself in 12 months when you have long forgotten what it does or why you did it that way’ and those that do thank me in 12 months when they are asked to go back to update or maintain their code.
A new set of rules needs to be imagined for how the risk associated to citizen development can be managed alongside the benefit. What will these rules look like? I really do not know – but I do know that without them organisations are accumulating both risk and technical debt that may become impossible to manage in the future.
It is a tricky one, for sure.