12 January 2009

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.

5 comments:

  1. To be fair, my rant was specifically about XP, NOT about Agile in general. Not every big-A Agile methodology has the precise set of points that I think turns off alpha programmers.

    Also, my second rant only talked about Agile in the context of general absolutism (though I think you're right that the Agile camp tends to lend itself to purity about a whole bunch of things, which is kinda funny when you consider the number of named big-A Agile methodologies.... like religions, they can't all be right).

    ReplyDelete
  2. I know we're talking informally here, but I think even so we're conflating two - theoretically, anyway - orthogonal traits: aptitude and attitude. Once you separate these, you realize that the aptitude matters, but the attitude - of each person in the group, not just the one with the highest aptitude - explains much of your intuition about team size. This reflects on Kirk's rant, which can be interpreted as arguing that aptitude begets attitude and and attitude isn't served by XP (pair programming especially).

    Even "Alpha developer"s with "bad" attitudes work fine in large groups (where "fine" means "productive", not necessarily "in a civilised manner"), as long as their responsibilities don't overlap (otherwise aptitude has to be applied/tested through the filter of attitude). This partially explains why happy teams often suddenly get disrupted when broad decisions have to be taken.

    ReplyDelete
  3. "Alpha" developers only annoy less able coders as they provide a constant reminder of what a talented individual can produce. No amount of "process" will make a mediocre coder good; processes exist to keep managers in work and auditors happy.

    Named software development processes (e.g. Agile, Scrum, etc) are the IT world's equivalent of self-help books. They push all the buzz-word buttons and provide "real-life examples" (that couldn't be more canned if Heinz made them); but ultimately they are 5% common sense and 95% wasted energy.

    ReplyDelete
  4. I think my point is that any methodology that involves Pair Programming is one that can ONLY be done if you homogenize your resources to the same level. By its very nature, that eliminates the ability to have exceptional programmers, who are so far above the normal developer that they simply cannot work at the same rate as their "pair," and even if they could, that's really stupid to try to get them to.

    Fundamentally, ANY strict methodology only works if you're doing boring work that doesn't require significant thought, just execution. You don't have alphas on those teams anyway by mutual agreement.

    ReplyDelete
  5. I think it depends on the type of software being developed, If the software is small then it requirement will be less and if the software is being big then more people will be required for that.

    Software Development India

    ReplyDelete