Recently, I stumbled over a post in X (formerly Twitter) in which Erik Meijer claimed that the introduction of Agile reduced the developers to user story implementation machines. Here’s the full quote:

When I warned developers nearly a decade ago that Agile is a cancer that needs to be eliminated from our industry, many thought I was crazy. But Agile has completely marginalized the role of developers to just mechanically implementing user stories handed to them by the product owner. Now, AI is the savior who will free them from this misery by killing the developer role.

This got me thinking. I agree with Meijer that quite frequently, developers are just executing the product owner’s wishes. As product owners are primarily interested in features (a.k.a. “user stories”), developers will mostly work on these rather than on more technical improvements like code refactorings. Many developers work for fake agile companies where they are disempowered. That means that they can’t decide which features will be developed in which order. In other words, they don’t control the “what”. In such a setup, the developer’s purpose is just to execute the product owner’s orders and to turn his feature requests into reality.

However, in addition to the “what”, there is a second dimension: the “how”. Many product owners have little technical knowledge, so they might be able to tell the developers what new thingy to build, but they cannot tell them how to build it. Enter the architects. Usually only found in bigger software companies, they understand how the code works (or at least they used to back when they were still doing actual development work). The architects can tell the developers how to build a feature, and sometimes they have a very strong preference for how it should be done and will accept no deviation from the master plan.

So, in an extreme case, the product owner and the architects together control both the “what” and the “how”. I have seen this in practice myself. The product owner writes a long document describing a feature and then passes it over to the architects. These then create a new document that describes the planned implementation, including what new classes to add and which fields to add to an existing class. After this is done, the architecture document is passed over to a developer, who will implement the changes. During the implementation, the developer might find edge cases that were missed by the architects. In this case, he has to discuss the issue with them so that a compliant solution can be found and the architecture document can be updated. Sadly, this is not a spook story or some tale out of the eighties. It happened to me back in 2015 at a company that still claims to be agile today and still uses Scrum as its main development model.

In this situation, developers are really just machines, executing the decisions made by other people further up the chain of command. In that sense, I agree with Meijer. However, I don’t think that Agile can be blamed for this (rather dysfunctional) working model. I’d argue that the idea that developers should just execute the given plan is way older. The distinction between “architects” and “implementers” is already mentioned in Fred Brooks’ “The Mythical Man Month” which was published in 1975, where he writes

Are not the architects a new aristocracy, an intellectual elite, set up to tell the poor dumb implementers what to do? Has not all the creative work been sequestered for this elite, leaving the implementers as cogs in the machine? (…) As to the aristocracy charge, the answer must be yes and no. Yes, in the sense that there must be few architects (…) and the architect sits at the focus of forces which he must ultimately resolve in the user’s interest. If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology. No, because the setting of external specifications is not more creative work than the designing of implementations. It is just different creative work.

As we can see, Brooks clearly rejects the idea of an egalitarian development model. So, even more than fifty years ago, way before Agile existed, the “how” was, at least in some companies, not under the developer’s control. OK, so how about the “what”? Before Agile took over, waterfall planning was the standard development model for software. Here, the “what” was determined by a small group of expert planners at the very beginning of the project. At that point, only a small handful of programmers (if any) were even part of the project staff. Both the scope and the time line were determined in advance. It was a purely top-down approach. In many companies, the only difference Agile has made is that it has reduced the level of upfront planning and replaced the project manager with the product owner. In that sense, developers have always been feature machines. There are (and have always been) exceptions to this, of course. For example, the 1994 video game “Warcraft: Orcs & Humans” credits the whole company for the game design, as everyone had a say.

So, where does this leave us? I think Meijer is wrong to blame Agile: as I’ve demonstrated in the above paragraph, developers have just been machines to execute a plan way before Agile existed. However, I think he touched upon another important question: what level of empowerment should we strive for as developers? In a top-down company, we can expect very little say regarding the “what”. The company might use Agile on paper, but that is irrelevant if it doesn’t match the company culture. However, even in such rather grim circumstances, we must at least take control of the “how”. Relying on the architects to define the “how” is not a good idea, as they are way too detached from the actual situation in the metaphorical trenches to come up with great solutions. Instead, we should rely on the subsidiarity principle to find the best possible solution. Of course, this also means that we will take responsibility for the quality of our work and have to accept the consequences. However, I think that’s something every developer worth his salt will do without hesitating. The downside of this approach is that different developers in different teams will come up with different coding styles and concepts. This might undermine the conceptual integrity of the full product, as Fred Brooks has warned. Nevertheless, I think we should still push for control over the “how” as I think the idea of conceptual integrity by a central committee doesn’t work in practice.

Taking control of the “what” is only possible in an actually empowered “bottom-up” company. These companies do exist, but they are a minority. I think that “bottom-up” companies have a fundamental advantage as they make better use of the subsidiarity principle. It’s important to keep in mind that feature requests are primarily requests to find the solution to a problem. When thinking about it in more detail, you might come up with something completely different from what was originally requested. For example, imagine you’re in charge of a time off application that is used by companies to keep track of the time off taken by their employees. You might get a feature request to allow an export of all vacations of an employee in a certain format. Rather than just building this, it’s a good idea to understand the reason behind the requirement. It might just turn out that the customer actually wants an automatic integration in Outlook and just requested the data export as a work-around. Questioning requirements can expose better solutions. Such a reflection on requirements happens more frequently in “bottom-up” companies where the teams actually own their products. I think it’s a superior way to run a business, but it’s outside our control. We either work for such a company or we don’t.

Last, let me briefly talk about AI and development. I think that large language models are conceptually unsuitable for development work and, hence, am not worried about them. I don’t think that people who want to replace developers with AI actually understand what developers do.

Conclusion

Agile isn’t to blame for reducing developers to feature machines. Developers should always strive to control the “how” and take control of the “what” only if the company culture allows it.

If you liked this blog, please share it with somebody. You can also follow me on Twitter/X. And if you want to acquire even more knowledge, then please check out my other posts on this blog.