What The Simpsons can teach us about the faith of citizen developers
Over the last months, I have talked to thought leaders and developers of different no-code and low-code solutions on their perspective of the citizen developers. Here, I want to share one view.
The tale of the Citizen developers
Have you read the tails about the citizen developers yet? They are center stage for the vision of the future of software engineering and digitization within companies. They are the superheroes who help overcome the impermanent shortage of developers. They are everywhere. They are part of every business unit.
During the day, they perform the daily tasks their job profile requires. At night, they become the workforce to develop the future business application a company needs.
At this point, you might ask yourself, how is this possible? How can an untrained citizen developer design business applications? How do they know of all of the frameworks they need? No-code/low-code platforms tell the tail that with the use of their tools, everyone can become a developer — a citizen developer.
There are many reasons and arguments why I don’t fully buy into that story. But for today, let’s start with one. This one reason has actually been demonstrated to us multiple times in business. I would like to take the metaphor of a Simpsons episode.
The Homer
Do you remember Homer’s car? I don’t mean his daily ride. I talk about “The Homer.” If you remember, you know where this is heading. If not, let me explain.
In Episode 28, Homers’ half-brother, Herb, comes to Springfield (Yes, Homer has a half-brother!). His half-brother is the supposedly better version of Homer. Better educated, better looking, better in everything. And he is the CEO of a large car manufacturer. Herb believes that the company should start to develop the car that customers want, not the car that the company tells them they want. That’s why he reaches out to Homer, an average citizen. Presumably, Homer understands the needs of the average citizen and the everyday user of cars. To Herb, Homer is the best person for the job and hires him to design the future vehicle.
So, without further ado, let me present the car built by and for Homer. The Homer features two bubble domes to keep the quarreling kids on distance. The engine sounds are so loud that pedestrians should think, “the world’s coming to an end.” And the (three) horns play “La Cucaracha.” I could go on with the feature list, but I think you get the idea.
Maybe needless to say, that car was a massive failure for the company. The development was costly, and no one liked it except Homer.
What is the moral of the story?
Well, many things can be taken away from this. For instance, you should probably not bet your company’s future on your half-brother that openly hates you.
Users know what they want, not what they need.
But, for me, one of the main takeaways is that users know what they want, not what they need. We should not assume that just because people have wished for features on a product, this automatically means that these features should be part of the product. They might want a feature, but are they also willing to pay for it? Do these features enhance the overall experience? Or could these features even break another more critical aspect? For instance, Homer’s desire to separate the kids might make sense in his mind. Still, it might negatively impact the car’s aesthetics, which is even more important to other users. Besides, the needs of one user may not be representative of all the requirements.
On top of that, Homer, just like citizen developers, is not formally trained in certain aspects of car design. That’s why there are people whose occupation is to develop business applications. They are trained to do so or have tons of experience. They know how to derive the needs of the customers. They know how to design an application to suitably fulfill the user’s needs. There are specialties for different jobs (e.g., Back-End, Front-End, UI/UX Designer). Why do we assume, with the right tool, the citizen developer can now take over this job others have trained years to achieve?
Today, many no-code/low-code platforms are promising the revolution of the citizen developer to CIOs. Well, maybe in the future this will be possible. However, the reality looks very different from this. Just this week, I have asked a representative of a no-code/low-code platform, based on his experiences and customers:
“Who is developing the applications with the platform?”
His answer: “IT.”
Collaborate with the user instead
That does not mean that the user should not be involved or that no-code/low-code has no future.
On the contrary, the user is a fundamental part of the developing process. Even different methods are available that put the user in the center of attention. If you follow any of these methods, there should be a close collaboration with the user. But the user should not become the developer of the application.
Instead, we might not want to think about the user and the developer as two different camps fighting each other. Instead, development platforms should offer no-code and low-code parts that support the collaboration processes. For example, the development platform might make interface designs faster available to users. Also, complicated rules could be expressed in a more accessible format using no-code and low-code elements. Aspects like this can create a basis for discussion and help the developer receive feedback and involve the user better in the processes. If done right, the user can get involved in building a business application.
As I mentioned in the beginning, there are many reasons why the idea of the citizen developer does not fly. The stated reason is just one of them. If this is interesting to you, I might come back, later on, to talk about the other ones.
