You can describe developer cultures in myriad ways. Here’s a division I find useful as a quick orientation when looking at a development team.
In stereotypical MBA style it’s thinking about the world in two dimensions, with two categories in each dimension. The vertical asks: How often does the team deliver? Frequently or infrequently? The horizontal asks: How robust is the quality of their work? Are they rigorous or careless?
And then we get four categories of team culture:
- Performant teams deliver frequently and are yet robust in their quality control.
- Cowboy coders deliver frequently but are careless about their code.
- Bureaucratic teams are very, very careful about the code they put out, but they deliver infrequently.
- Money pits combine the worst of both worlds: they delivery rarely, and when they do the quality is awful.
Some notes on these:
- Performant teams do not come about by accident. They require investment in various kinds of automation to ensure their high quality and frequent delivery happens by itself and reliably. Modern codebases are more likely to be maintained by performant teams, because it’s only recently the supporting technologies have become commonplace, but it’s very easy to start off on the wrong foot, or to slip back to one of the other categories.
- Cowboy coders can be very successful individually, because they know their own code inside out, but they get dangerous when others start entering the picture: someone to be responsible for environments, other developers, and so on. Then the lack of robustness becomes more visible.
- Bureaucratic teams usually miss the automation of performant teams, and use checklists and other manual processes which slow them down. I often find there is an underlying fear of delivery, because they don’t trust their code enough to let it out the door often.
- Pure money pits are rare in my experience, and typically exist when the development team is a vanity function that the organisation can afford to keep without caring about its impact.
Most organisations find it difficult to move along one axis without also moving along the other. Specifically it’s hard to increase rigour with slowing down. The hidden variable is time or money: it requires organisational commitment to move purely rightwards or purely upwards.
Clearly all this is rough and ready, and the shortcomings of such a categorisation mechanism are numerous. But as rough and ready mechanisms go, I find it can be a useful shortcut, and then we can start a conversation to explore the details.