Divinity and the ‘Citizen Developer’

It is a term of derision, a key piece of Microsoft marketing and a term I have little time for. It is ‘Citizen Developer’. In the unlikely event you are unfamiliar with this term, it is the persona used by Microsoft to describe the benefits of their Power Platform. While I could not discover who invented the term, it is one which has been strongly embraced by the Microsoft marketing engine.

The reason they have embraced it is obvious. As evidenced in some of my previous posts, it is not hard to use tools like Flow, PowerApps and Power BI to add real value to an organisation with little to no code or scripting. This opens up the way for non-coders to build powerful business applications, previously the exclusive domain of coders. The rise of the Citizen Developer.

To be honest, this is not really a new approach for Microsoft. In the past Microsoft used the term ‘Power User’ and this has always been the focus for Dynamics innovation. Certainly as far back as the product moving from v3 to v4, there was a deliberate move to give power to administrators who wanted to tinker without code. Back then I used to say you could get 70% of the way towards a production-ready application using just configuration. With each major release that percentage has increased and it is very possible to build production-ready systems these days with no appreciable code in them.

In parallel, as workflows matured and the product became more and more flexible, there was a breed of coders who grumbled that feeding the power user was a terrible idea. Limiting the power to create exclusively to coders reminds me of the days when bibles were written in Latin and the only people who could read them were the priests. The priests had exclusive access to the divine and all others had to go through them. Thankfully times have changed.

I have experienced this resistance to the power shift first hand. In the days when my blog featured cute tricks with workflows, I used to hear it a lot. Coders I spoke to would complain that processes should be handled with code; that splitting processes across different technologies meant an administrative nightmare and offered no value in the long run. Also if the power of workflows were given to end users, it would be a disaster with them going rogue and creating an unmanaged mess. We hear the same fear and uncertainty today with Flow and the fear of ‘Shadow IT’; the creation of apps and processes unsanctioned by the administrators.

I agree that things must be managed but the perspective that the solution is to keep power with the priests misses the point. When development was restricted to the few it was easy to administer, now that many can develop it is harder but it is not the wrong approach.

There are two obvious benefits to giving access to creative power to non-coders. Firstly, it frees up coders to do more interesting work. Rather than writing routines to perform dull busy-work they can cast their minds to more interesting and unique problems. Secondly, it gives non-coders a much greater appreciation of what coders do and how they go about it.

The answer to managing this new world is collaboration and discipline. Standards and conventions need to be put in place to ensure Workflows, Plugins and Scripts all work together, rather than against each other. The idea that giving non-coders power is the problem is not true. Undisciplined power is the root of the problem. I know many a Dynamics system that came undone on upgrade because a coder decided it would be easier to use unsupported methods to develop a system. Just as with the priest, the coder is human. In the new world, what separates the good and the bad ones is not exclusivity to power but their approach to their work and their ability to work with others.

Just as the role of priests in society has evolved, so too has the role of the coder in modern software development. A good coder, having experience in managing the development and release of software, has the responsibility to guide others starting out on their journey. Thankfully the way we approach software development has evolved to accommodate this new perspective. Agile has meant a greater focus on release management and DevOps and variants such as Scrum are clear that there is no ‘i’ in team. The ‘development team’ makes no distinction between those that can code and those that cannot.

The idea of coders and non-coders being equivalent in terms of software development sits much better with me than the divisive idea of ‘coders’ and ‘Citizen Developers’. While a traditional coder may well say Flow is what Citizen Developers use while ‘true’ developers embrace Logic Apps, the fact is both tools have their place in software development and many coders appreciate and gain much benefit from their use of Flow.

The fact is the relevance of coders and priests does not derive from exclusivity and while many considered the change in exclusivity tantamount to blasphemy, the experience for all is much richer today because of it.

I have faith that, over time,  we will move away from terms like ‘Citizen Developer’ and embrace the idea that anyone who builds is simply a developer and the tool used to get there is irrelevant. What is more important than the tool used is the approach used by the entire development team to deliver a robust solution. That vision of the future is something I can see myself believing in.