The exceptions to Brooks’ Law
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 people often use laws like this in a lazy fashion to end debate, assuming it is as universally applicable as an actual law of basic physics. It doesn’t take much effort to see that there are important exceptions. 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. Brook’s 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 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 resilient to change. They 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 of 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 on boarding 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 manager’s 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 personnel: 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, only thoughtful consideration for how it is applied. All additional examinations or applications of Brook’s law, or these exceptions, are welcome.
See also:
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.
Sorry that’s “Brooks’ law”, and nice blog btw.
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.
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).