The Code Whisperer

In his 1975 classic book The Mythical Man-Month, Fred Brooks states “adding manpower to a late software project makes it later”, which has become known as Brooks’ Law.

Generally this is correct but few rules are true without clarification and this is no exception.

The basis of Brooks’ Law is that adding people to a project increases the communication required and, assuming they have no knowledge of the development, will require training, usually by those struggling to finish the development. How long it takes before new team members are productive and how much of the existing team member’s time is taken varies massively from one project to another. Another factor is whether the remaining work can be cleanly split up or “partitionable”. I have seen panic project management where three developers are working on the same code module, inevitably slowing the whole process down.

Before rejecting the idea of adding more resource to a project, late or otherwise, consider the following:

Is the project actually late? - if the estimates and plan are wildly optimistic and unattainable, you aren’t as late in the project as your plan suggests. For example, you estimate a project to take 3 man months and have one person working on it, but in reality it will take 6 man months. After 2 man months you realise the project won’t deliver on time and reject adding another team member as there is only 1 man month left and this could add another 2 weeks to the project. However in reality you have 4 man months of work left. This is an important point because a crucial part of Brooks’ Law is adding manpower to a late project and this refers to a project that is late in terms of the amount of work and people and not by an over optimistic plan

How far into the project are you? - it’s obvious the closer to the beginning of the project you are the greater the impact of adding extra team members is. But to go back to the previous point, you must know exactly how much work remains on the project. In our example we are 2 man months into a 6 man month development. Adding more team members is unlikely to bring the project back to 3 months of elapsed time as originally estimated (1 person on a 3 man month project), but provided the work can be partitioned the delivery time can be reduced from 6 elapsed months. Let’s say that training up a new team member takes 2 weeks, although this will differ with project complexity and team member knowledge, so both team members are un productive for the 2 weeks. We’re now 2.5 elapsed months in with 4 man months of work left. Assuming the work can be split 50/50, the remaining work will be finished in 2 elapsed months, giving a total elapsed time of 4.5 months rather than 6 if we had kept only one person on the project

The project in my example is later than initially expected, by 1.5 months, but this is due to poor estimating rather than Brooks’ Law and in fact was delivered 1.5 months early by adding an additional team member at a point in the project that according to the original plan would have been classified as a late project.

An additional benefit of increasing the size of a team is that the knowledge of that project is spread amongst more people, which, depending on what happens to that project in the future, may be a valuable asset worth sacrificing a period of productivity.

By not clarifying Brooks’ Law with these 2 points and not taking the opportunity of adding resources to a project that will benefit from them, not only do you delay the project you also run the risk of inviting heroic action in an attempt to bring the delivery date back. Not revising the plan instils a culture of having deadlines that are known to be impossible to attain, but viewed as a challenge not something to be refined.

In summary:

If your project is late check the estimates and if wrong revise and re-plan. Use planning tools to model the effect of a period of unproductiveness followed by increased resource. By doing this you can make a considered decision about whether to add people or not. Before adding team members be absolutely sure that the remaining work is partitionable and that the new team member(s) will fit in well with the team.

Further reading:
www.stevemcconnell.com/ieeesoftware/eic08.htm
en.wikipedia.org/wiki/Brooks’s_law