Quite often I am asked the question: “How do you manage technology choices in a team?” In the discussion, often someone argues that developers should rather not make technology decisions by themselves. Otherwise the project would fall into chaos and anarchy because all conceivable technologies would be used. After all, developers are irresponsible and childish! But the ones who suffer the most when projects end in chaos and anarchy are actually the developers. So it is in their best interest to think hard about technology choices. Interestingly enough, this fact is often ignored in the discussion.
The next level are statements like “My 14-year-old daughter also knows how to program. She can get it done faster than these developers!” or “With the developers here you can’t realize modern ideas anyway”. Developers are highly qualified experts. Software is one of the most complex things that humankind can produce. I consider such statements to be simply disrespectful.
Control
But let us assume that developers are indeed irresponsible and childish. Then the only thing you can count on is controlling them, it seems. This will lead to clear guidelines, for example regarding technologies to be used or coding standards, ideally with automated checks to enforce them.
Of course, such measures can be useful. But controlling and enforcing often works poorly: In one of my first larger projects, we defined some coding guidelines together and used tools to automatically check them. After some time the tools reported no violations against the guidelines any more. However, some developers had simply deactivated the tools at certain parts of the code. That way a pointless competition can be started with more and more controls and then undermining the controls.
Obviously, you get nowhere this way. And control doesn’t scale: a single person can’t understand, control, and correct everything that an entire team produces. If you try to do so, you will fail. Also the empirical “State of DevOps” study shows that a heavyweight change process has a negative impact on the performance of the software development organization. More control and overhead are therefore hardly the solution.
Solutions
Fred George once roughly said: “Developers want to tinker with things. So give them things to tinker with!” That is why his model provides extensive freedom for developers. They don’t just tinker with the code, but also with business goals such as increasing sales or customer satisfaction. Interestingly enough, the model is called “Developer Anarchy”. How could this possibly work? After all, developers are irresponsible and childish!
Maybe developers are actually responsible people? After all, I do know some developers who manage considerable budgets in their private lives at their own risk - for example when building a house. They also take responsibility for their families and spouses. Of course, that is nothing special - it just means that all people, not just developers usually act responsible.
Skills are also important to developers. They take pride in their work and are eager to learn new things - that’s why they might seem playful or even childish. Some even program in their spare time and take part in evening meetings or code retreats on weekends, for example. This shows that they are highly motivated to constantly develop their skills, even in their free time.
Respect
In my opinion, the only way out of this situation is to start respecting developers and their qualifications. I consider them to be specialists for code - which they are.
Trust and delegation can change behavior and be a prerequisite for responsible action. When developers are forced to implement decisions that in their eyes make no sense, they will try to undermine those decisions. If the whole project seems pointless, they will look for places to play around in. But when developers make decisions themselves, they will have to act differently. They cannot just criticize, they have to be constructive themselves. They also have to live with the consequences - so they will think about the decisions carefully.
As a term for a step towards more I like “Leap of Faith”: You believe in the developers and jump into the unknown, which of course requires courage. If their approach can be improved, control is of no help, because it can be undermined. Instead, the focus should be on knowledge exchange and knowledge transfer. If developers have understood both the goals and their technical implementation, there is a relatively high chance that they will follow the concepts of the technical implementation. And if not: Perhaps the concepts are not such a good idea after all? Maybe the developers even have a better idea? This way, there can be open, productive discussions and improvements.
With this approach control is replaced by cooperation and different perspectives of the parties involved are exchanged. That helps to create even better solutions than would be possible by controls alone. Remember: Developers are specialists in their field.
Management
Of course, one can say that management and architect must finally show the developer the necessary respect and trust - and that’s the solution to the problem!
But respect is not a one-way road. Developers must also show respect and trust to management and architects. Otherwise, serious discussions are hardly possible. They are also experts - but in other areas. For example, architects can structure larger systems and management can take care of the organization.
tl;dr
Mutual respect and trust are the foundation for successful collaboration.
Many thanks to my colleagues Christoph Iserlohn, Robert Glaser, Anja Kammer, Michel Krämer, Martin Kühl, Stefan Tilkov, Hermann Schmidt, and Benjamin Wolf for their comments on an earlier version of the article.