In Fred Brooks’ Mythical Man Month, he states:

Brooks’s 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 The art of project management, 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.

See also: the social contexts of open source software, from the Cathedral and the Bazaar.

  • This site is powered with the magic of space age email to send my best posts to you each month. No hassle, no spam, no fuss. (privacy policy enforced by my Rotweiller)

You Will Like These:

7 Responses to “Exceptions to Brooks’ Law”

  1. Ben Bryant |

    The only good one here is “there are worse things than being later.” If you abandon the clear message of Brooke’s law in favor of death by a thousand caveats, you do a disservice to your readers. This leads to the kind of management that can argue itself out of any truth.

    Reply
  2. Ben Bryant |

    Sorry that’s “Brooks’ law”, and nice blog btw.

    Reply
  3. Jarno Virtanen |

    Steve McConnell wrote about the very same subject in his IEEE Software From The Editor column, “Brooks’ Law Repealed?”, in 1999:

    http://www.stevemcconnell.com/ieeesoftware/eic08.htm

    I, for one, consider Brooks’ Law just a good eye-opener for those not familiar with the dynamics of software projects (or other complex projects, for that matter). It is plenty enough if managers just realize that adding manpower to a project might not make it finish faster.

    Reply
  4. Pawel Brodzinski |

    There’s one more thing here. If you’re far enough from the end of the project a new person would eventually become a hard core team member and would no longer be an added guy. Again if it happens early enough increased productivity in the long run would cover cost spent on adding new person.

    By the way: you should highlight some old pieces of yours more often. They’re surprisingly actual (and as good as always).

    Reply
  1. [...] build on Brooks’ law from Scott Berkun: “The trouble is that there are important exceptions that many people don’t take the [...]

  2. [...] I agree with the law, there are important exceptions I’ve identified -

Leave a Reply