Turn your IT department into an enabler of citizen development
I recently read Bryan Bates’ well-researched and balanced article on Citizen Development in the context of Agile practices.
He definitely has the right idea about low-code platforms being the path to relieving the pent-up demand for business applications that talent shortages create and that competitive pressures aggravate. He does a good job tracing the history of no-code, and of describing some of the benefits and constraints.
However the no-code space is vast, and there are options that he does not know of. These options dramatically change some of the assumptions his article is based on.
But first: why is there a picture of a clay model of a car in this article?
I believe it is important to explicitly understand the market dynamics that are playing out in corporate IT and to address the underlying causes more proactively than simply using no-code as described in the article and waiting for someone to build a better no-code system one day.
What are the market dynamics and underlying causes? The almost complete failure to apply industrial production techniques to application development.
Very few people would disagree with the assertion that one cannot possibly hope for a successful application development project if the development team consists entirely of new and/or relatively unskilled developers. Everyone accepts as a given that without at least a few master craftspeople guiding the project, there is no hope of succeeding in creating robust and scalable code.
Compare this to automobiles. If you traveled in a car today, you just trusted your life to an exceedingly complex piece of machinery, that could easily kill you if anything went wrong, but was assembled by someone without an engineering degree, and who might not even understand how most of the machinery in the car works. Yet every day a few hundred thousand motor vehicles are completed, 80 million per year, all due to the magic of industrialization.
There are many competing ideas of what industrialization really means, but I will give you a definition that think is better than any other.
Industrialization is the ability to mass produce products while maintaining very high quality, preferably better quality than would be achievable by hand crafted production.
The way industrialization is achieved is not by mere multiplication of brute force, but by embedding human skill into machinery so that unskilled humans can produce some as if they had the necessary skill.
The thing to note about automobile production is that no one tries to automate the skill in the creative process. Car manufacturers still use clay models. They still hire top-notch engineers to create prototypes and calculate the performance parameters. The part that is highly automated is the assembly of mass-produced components manufactured to very high tolerances so that they fit together the right way every time, no matter how unskilled the person doing the assembly is.
The difference between skill and force
Let’s take a very simple example from your kitchen, the difference between a food processor and a rice cooker.
Food processors multiply brute force. In the time it takes you to dice 1 onion, it can dice 10. It can whip egg whites in a 10th of the time and with almost no physical effort on your part. No doubt, they are fun things to have around. But would a top chef ever use one to cut vegetables for their signature dish? Can a food processor help you make 100 radish roses in the time it would take you to cut 10? No.
Now consider the humble rice cooker. Do you need to watch over it? Does it ever burn the rice? Or undercook it? No. Can someone who has never made rice before in their lives make a perfect bowl of rice just by following simple instructions? Yes. Even top sushi chefs - people notorious for their attention to every detail - use rice cookers. This is because the rice cooker has skill embedded into it. Skill as good as the very best human chefs alive. And a completely unskilled person can use one to create rice as good as if it was made by the best chef alive, which means that there is no longer any practical limit to how much rice can be cooked. It is simply a question of buying more rice cookers and hiring the first person that walks in the door.
Isn’t coding different?
If you believe that this does not apply, or impossible to achieve, in the case of software, then you need to take a closer look at compilers. Once upon a time, top-notch programmers would refuse to use compilers because they could write better code by hand. Today only a lunatic would suggest that all machine code should be written by hand. A compiler will do a much better job, every time.
And compilers are used much more than you think. The web page you are reading now is the result of dozens of intermediary compilation steps. C code was compiled to make the Apache web server this is probably running on. Then there is your web browser. Perhaps you are using Google Chrome, it was written in C
So programming already uses industrialization in a very limited sense. Every day, billions of lines of machine code are mass-produced by compilers that do the job with higher quality, reliability and safety than if the same code was being written by hand.
But this is only the beginning. There is so much oppotunity to apply industrialization to the rest of application development.
What are these new options?
What IT needs to industrialize is to adopt a similar approach. Currently, we take our best engineers, and we tie them up by putting them on our most important projects. What we should do instead is put them on creating components that can be easily (and safely) assembled by less skilled developers.
Large IT departments should be building their own proprietary no-code platforms, dedicating their top talent to maintaining these platforms, which can then be used by junior programmers, business analysts, and tech-savvy business people to assemble apps out of pre-built, pre-tested and debugged, drag and drop components.
Frameworks already exist to accelerate this process so IT departments do not need to reinvent the wheel. Some of them offer pixel-perfect UI controls, the ability to change the way code is generated, and total source code visibility with no “black boxes” or proprietary libraries to worry about.
These tools do away with the restrictions or concerns Bryan Bates lists: licensing, specialized capabilities, performance tweaking, and top-notch UI/UX because the IT department has the ability to build all of this into a no-code platform that they totally control.
Why should IT want to do this?
The benefits to business are clear, but there are also many benefits for the IT department. A few of the most important are:
Fewer bugs. Once a component is debugged all future uses of it are safe.
Truly Agile. With an average dev time of 2–3 days for a new component, who needs project management?
Lower governance costs. With components being for reuse by definition, all dev work is automatically capitalizable, who needs stage/gate?
More satisfying work. What senior engineer enjoys moving a button two pixels to the left? Designing for reuse is inherently more interesting than pushing out “compromise code” to “just get it done” by some deadline.
The real new face of Agility is not bypassing the IT department. Businesses tried that in the 90s and it didn’t work. The real new face of Agility is fundamentally changing the way the IT department works: getting it out of the business of projects and into the business of platforms, no-code platforms for internal use.
Adam Zachary Wasserman is the author of The Chaos Factory: The inside story of IT failure, available at www.chaosfactorythebook.com