Jiri’s Notepad

Good build on Brooks’ law from Scott Berkun:

“The trouble is that there are important exceptions that many people don’t take the time to consider when using Brooks’s law[…]

• 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 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.
• 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.
• 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.”