In Fred Brooks’ Mythical Man Month, he states:
Brooks Law: adding manpower to a late software project makes it later.
In the book he notes that it is an “outrageous oversimplification”, but most laws of this kind are. The trouble is that there are important exceptions that many people don’t take the time to consider when using Brooks’s law to justify something. I hinted at them in chapter 2 of Making Things Happen, but here’s a full explanation of the notable caveats I’ve seen.
- It depends who the manpower is. The law assumes that all added manpower is equal, which is not true. Given the choice of adding a good programmer, who knows the code base and is friends with half the team, I’d consider it. Knowledge of the code and good relationships with the team offsets the two key reasons for Brooks law (ramp up and communication overhead). And if that individual has prior experience coming in late to a project, all the the better. Some people are capable of playing the SWAT team / Ninja role, and that skill is orthogonal to programming talent: some are simply better are getting complex work done on unfamiliar terrain with a minimum of disruption.
- Some teams can absorb more change than others. Some teams are more resiliant to change. They can can absorb communication overhead and teaching duties better than others can. It’s well known that there is a wide range among programmers in their speed, but it’s also true there is a wide range for communication and teaching skills. Even if all teams pay a price for adding people, that price will vary widely and is not a fixed cost based on the # of people alone(e.g. n*n).
- There are worse things than being later. The conclusion most people reach is that, given Brooks law, you should never add people. But it doesn’t say that: it just says you’ll be later. That can be ok if you also get higher quality (not a guarantee of course). Time is not the only success criteria. If the person you’re adding fills an important hole in in the team, being later might be worth it.
- There are different ways to add manpower. The sad but popular approach is to throw people in without much explanation and let everyone figure it out for themselves. But if the manager clarifies why Sally and Rupert are joining, and defines good roles for them, with input from the team, they’ll be set up to make a smooth transition. This can also include assigning them a mentor who is capable and motivated to be their primary point of contact for ramp up issues. The more experience everyone has with mid-stream personnel changes, the better. Some tasks will always be better suited to assigning new people and it’s the managers task to figure out which ones those are.
- It depends on why the project was late to begin with. If the project was late because of inexperience or poor team practices, adding a small number of experienced people with those missing skills, and directing others to follow them, can eliminate some of those inefficiencies: not all knowledge or skill transfer requires long lead times. Therefore the added value of certain manpower is not just 1 additional programmer unit, but 1+, as they have a positive effect on the productivity of others. But more importantly, there are many reasons for being late that have nothing to do with the programming team personel: no amount of programming staff modifications will resolve the psychiatric needs of team leaders or the dysfunctions of executives.
- Adding people can be combined with other management action . Contrary to popular belief, management is not a turn based strategy game. You can do more than one thing at the same time. For example, you can remove someone at the same time you’re adding manpower. This does increase volatility, but if you’re removing your worst, and most disruptive, programmer and adding one of your best, it can be a reasonable choice. Managers also have the option to cut or reorganize work across the project, improve tools and equipment, throw a social event to accelerate team relationships, etc. There are always ways for managers to provide cover fire. These all have disruption costs, but depending on the length of the project they might be offset.
Disclaimer: I’m sure there are specific cases where these exceptions do not apply. I am not suggesting the abandonment of Brook’s law or that religious adherence to the above. All additional examinations or applications of Brook’s law, or these exceptions, are welcome.