You Might Have Too Many Developers

How the bloody heck could I have too many developers? That makes no sense.

To Do an Agile Conversion

Slaves

Before you start looking for ways to scale agile, let's do a simple thought experiment.

Suppose you have 2000 developers on a project.

You already know some developers are more effective than others.

What if you could find 1000 within the 2000 that collectively are twice as effective as the other 1000?

Couldn't you do the same amount of work with half the developers? Wouldn't that be much easier to manage?

What if you could find 500 within the 1000 that are collectively twice as effective as the other 500?

Couldn't you do the same amount of work with half the developers? Wouldn't that be much easier to manage?

How far could you take this?

Joel Spolsky has claimed the best programmers can be as much as 10 times more effective than the worst programmers.

If that's true, couldn't you do all the work the 2000 developers do with 200 or so?

Wouldn't that be much easier to manage?

This Quora article has more data:

In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements!

-- The Mythical Man Month

Joel might have a point that hiring a fleet of average developers might actually be slowing you down.

Three rules of thumb seem to apply whenever you measure variations in performance over a sample of individuals:

  • Count on the best people outperforming the worst by about 10:1.

  • Count on the best performer being about 2.5 times better than the median performer.

  • Count on the half that are better-than-median performers outdoing the other half by more than 2:1

-- Peopleware

Add in the overhead of coordinating 2000 developers

And smaller teams start to make more and more sense. The concept of one or two 10 person teams writing software a 2000 person team wrote becomes feasible.

Even more amazing, Joel broke down the data to only include the top 25 percentile, and the data held! Even within the top 25%, the best outperformed the worst 10:1.

So even if you claim you have the best 2000 developers in the world, there's probably 200 of them or so that will still outperform the rest 10:1, and 20 or so within the 200.

Say 10:1 is false. Say it's more like 5:1 or 3:1 or even 2:1, combined with benefits like:

  • Reduced communication, integration and planning overhead
  • Better developers write cleaner code, so features go in faster
  • Better developers write fewer bugs, reducing rework
  • Fewer developers in the code reduce implementation divergence, making the code easier to read and change

You'll still be able to do that 2000 person project with one or two teams of 10.

The Mythical Man Month and Peopleware are not new. They've been around for over 28 years. Before Scrum, Extreme Programming, and all the other Agile methodologies.

Joel wrote the above mentioned article in 2005. Ten years ago and we still have 2000 person 9-12 month projects.

So why are we still talking about scaling agile with things like SAFe when the root problem is you might have too many developers?

Footnotes

No really, architecture groups are a bad idea.