First of all this post has nothing to do with babies. It is actually about an interesting phenomenon that affects house builders, software developers, the government and possibly all types of jobs. Without adding too much hype it’s about Brooks’ law, so those of you familiar with it can move on to the next post.
Let’s say you are a contractor and you currently employ 2 builders. Assuming the 2 builders work 40 hour weeks, you estimate that a house will be finished in 4 months’ time. However for some reason the client isn’t happy about this and would like the house to be built-in 2 months. In this case the contractor would employ another 2 builders thus doubling the productivity and finishing the house on time. If half way through the job one of the workers gets hurt the contractor puts more people on the job to make sure that the deadline is met.
Unfortunately if you had to do this in software development the results would be catastrophic. To understand this better we first need to understand the nature of software development. When one developer is in a team, let’s call him Bob, he is familiar with all the code, and if he is smart enough, any technical questions can be answered either by Google or by himself since he wrote all the code. When Sam, another developer, is introduced to the team he will need to become familiar with the code produced by Bob. Sam then starts to produce his own code and thus introducing some aspects of the system which Bob isn’t familiar with. In this case you’ll need both Bob and Sam to answer the technical questions. This also means that Bob and Sam need to constantly share ideas between themselves, thus periodically interrupting each other.
In order to get their job done Bob and Sam need to store loads of information in their short-term memory including:
- Variable names
- Method names
- Commonly used API calls
- Other parts of the system which might be effected by the code they are updating
- Race conditions
This also means that when Bob gets interrupted by Sam, Bob has to stop what he is doing to reply to Sam, then needs to start getting himself back in “the zone” and makes sure he re-obtains all the required information i.e. time is wasted on context switching. Let us assume that Bob needs 4 mins to get back all the required information stored in his short-term memory and let us also assume that Bob has to interrupt every other team member 4 times a day. Plotting this information we get the graph below:
As you can see when 31 members join the team no work will get done because everyone is getting too many interruptions.
But wait… this is not entirely correct first of all I pulled out the numbers out of a hat and secondly we are basing this on the fact that Bob had to ask all his team mates 4 questions a day. One can argue that you can limit the number of interruptions by adding documentation thus Bob can refer to the documentation instead of interrupting Sam. However when adding more team members this doesn’t only affect the number of interruptions, but also has an impact on:
- Decisions that need to be taken as a team are greatly affected, sometimes it’s hard to get an idea agreed by 3 developers, let alone by 31.
- There is a great overhead to induce 31 developers.
- Time spent in meetings is also greatly affected. If 31 developers speak for 2 mins each, you get a scrum meeting which lasts slightly longer than an hour.
- To create documentation you might need to consult with 31 developers.
- And I don’t even want to think what a nightmare it will be to plan the tasks and manage a team of 31 developers.
Anyway you see it, adding more people to a team will not get the job done faster, on the contrary Brooks’ law states that:
“Adding manpower to a late software project makes it later.”
There is of course the optimal number of developers to get the right balance between the work produced and the time it takes to finish a project. This number tends to vary both on the nature of the project and the experience of the team. If you record sprint velocity it is always interesting to see what happens when someone is on sick or on leave for a sprint.
In general, teams which require communication amongst themselves do not scale. For your reference the number of communication channels in a team can be found by using the below formula, where N is the number of members in a team:
Communication Channels = N(N-1)/2
For the non-developers reading this post, this is why the government is so inefficient because we elect more than 60 members of parliament (1770 communication channels, for those doing the Maths) who all want to get their ideas across and convince the rest of the members that their idea is the best.
To conclude I don’t believe that you should have more than 7 ± 2 (The Magical Number Seven, Plus or Minus Two) team members which amongst themselves do the required roles to deliver the project: planning, architecture, development, testing, project management, gathering functional requirements, documentation etc…