Growth

I’ve seen companies which try hard to grow1. I often can’t see the point in getting more people to work for them. Investing in the current people pays much more, I think. If you take the span of bad people to very good people which can be ten times more productive2, wouldn’t it be worth to invest five times more money and time into these people than hiring more and more? Every single person increases the communication effort and slows the whole organization down. Whereas a slim, highly productive team increases the quality and lowers communication effort.

More productive?

There are many factors which influence the productivity of people in software development.

  • Speed (Function Points per Week)
  • Defect rate (bugs per Function Point)
  • Communication effort (knows how to use Google and Books)
  • Cost (Cost per Function Point)
  • many many more…

Lets compare two groups of developers, one slightly better than the other5.

Developer FPs/Week Bugs/Fp Euro/Week Euro/FP Additional communication-effort
A 100 0.01 1200 12 0.05
B 66 0.02 800 12 0.10

So, developer A is clearly more productive than developer B, but costs more.

Imagine a project with 1,000 Function Points. It has to be code complete in five weeks.

Group of A-Developers

1,000 Function Points in five weeks are 200 Function Points per week. Our team has to consist of three A-developers. Ideally, three developers produce 300 Function Points, but we have to consider the communication effort: (3 × 100) x (0.953) = max. 257 Function Points. Cost: 18,000 Euro with a combined defect rate of 0.02973.

Group of B-Developers

This group has to consist of six developers. (6 × 66) x (0.96) = max 210 Function Points. Cost: 24,000 Euro with a combined defect rate of 0.114.

Summary

As you can see, a few developers which are slightly better than another group can easily outperform a double sized team:

Team Number of developers max. FPs Cost Defect rate Communication effort
A 3 257 18,000 0.0297 0.1426
B 6 210 24,000 0.114 0.4686

You could easily pay the A-Developers the double amount of the B-Developers and you would still produce a better4 product in the same time with the same expenses! Additionally the A-team still has more capacity left for changing requirements or unforeseen problems.

Again, wouldn’t it be far better to support and develop your current staff than simply adding more people?

1 In terms of “hiring people”.

2 The numbers came from two different sources. The first one is senior Siemens manager, and the second one is Paul Graham.

3 One minus the probability of no error: 1 – 0.993

4 More features or superior usability and less defects.

5 Never trust a statistic you didn’t fake yourself.

Adding manpower to a late software project makes it later.
— Fred Brooks