How many software developers does it take to write good software?

Kirk’s had a couple recent rants against the use of Agile if you’re an excellent developer and I thought I’d comment on this, but realised that it’s part of a different question which is how big the ideal development team should be.

My answer is that it depends on the situation.

Types of developer

To explain my thinking, I’m going to start by loosely categorising developers into three archetypes: Production-Line, Regular and Alpha.

• Production-Line developers: These are the ones where it wasn’t obvious that programming was going to be their life-choice – they weren’t born with the “programming gene” but for one reason or another ended up doing it anyway. Typically, they will need a lot of guidance, and are used most effectively in environments where they have detailed requirements given to them, strong processes around the way they work, and a large QA/test facility to ensure that what they produce works properly.
• Regular developers: These get what programming is and enjoy doing it. They are quite happy to take loose requirements and work out what the client really means by them, use a bit of initiative and produce good quality software at a reasonable pace. The level of process and testing needed around them is lower than Production-line, but they like working in an environment where there are clear goals and a road-map to take them there.
• Alpha developers: These are the people who know that they are the best developer around, and are not afraid to remind you of this. They typically score quite highly on the AQ test and are likely to rub people up the wrong way - partly because they always know best, and partly because they’re usually right. Alpha developers tend to really get into a particular technology (Python, Erlang, lambdas, WPF, MapReduce whatever) and try to use it for everything until the next shiny toy comes along. Processes annoy them (“just slowing me down, yo”). Detailed requirements annoy them (“it’s quicker to write the code than a requirement doc”). Unnecessary testing annoys them (“my code doesn’t have bugs, bugs are for losers”). Not being able to use the latest toys annoys them (“you chose the wrong technology”). But if you want innovation in your organisations then this is where to look for it.

Effect on development team size

Using the three different types effectively results in quite different team sizes:

• Production-line: Your team size is typically quite large (e.g. 20+), and a large proportion of the team is focused around activities other than straight development (e.g. project management, QA/testing, business analysis).
• Regular developers: Team size for an effective team usually doesn’t get bigger than about 8 developers plus a PM and maybe a couple of people for QA and business analysis.
• Alpha developers: Ideal team size is two, or maybe three if they have a (good) history of working together. One Alpha on his own will run the risk of not staying focused and also not having anyone to argue with about technology choices. More than three and you’re in for a whole world of pain and minimal productivity as they spend all their time arguing rather than developing.

So which kind of team do you want? It sounds like Alphas are best, but you also have to take into account the kind of company that you’re working in. Larger more traditional organisations typically like to have a lot of controls and processes around things as this allows them to tick boxes on audit reports that are issued from so far up the hierarchy that there is no visibility of what actually happens on the ground. They also have little appetite for the introduction of many new technologies or techniques as these are perceived to introduce unnecessary risk. And these are precisely the things that would drive an Alpha nuts. Plus if you really do have to churn out a big system then you probably couldn’t get enough Alphas to work together to be able to achieve it.

The result is a reasonable correlation between type of organisation, risk appetite, and kind of developers. To give some examples from the Financial sector:

But what about Agile?

I’m differentiating here between little-a agile (unit tests, continuous integration, refactoring and so on) from big-A Agile (total buy-in, stand-up meetings, Product Owner at the planning meetings, a near-religious fervour in defending Agile and creating new believers).

A lot of the agile techniques are used across all three kinds of teams very effectively. But Agile itself in my experience only really works for the middle group.

Team sizes for Production Line are too large to use Agile effectively as it’s all about communication. In Scrum for example, it's recommended that the ideal time size is about seven, and if you get bigger than this you start breaking into sub-teams to bring you back to the ideal.

Try to get Alphas to do Scrum and they’ll see it as a total waste of time and probably quit (or just use work time to do some pet project whilst complaining to anyone within earshot).

But for Regular developers it does increase overall productivity and also give other benefits such as client visibility/ownership that are usually desirable. I’m not sure exactly why this is, but my guess would be that this kind of size is about right for the communication-boosting techniques that are introduced, and that this kind of developer is receptive to a lightweight process rather than the kind used for Production-Line.

This is just based on what I’ve seen, and I’m sure that there are many people out there that can give counter-examples of applying Agile to small or big teams, but was it really the right thing to do or did you lose more than you gained?

Conclusion

If you’re building a team, think hard about what kind of people you want in it and how many, based on what you have to deliver and also what kind of environment you’re in. And make sure your methodology fits your team.