Thoughts on the Death of Brook's Law

Brooks' Law is wrong.

Brooks' Law (the pithy version) is: "adding people to a late project makes it later." There is some truth to that, but it's more nuanced. A bad manager staffs up a late project (in an act of desperation?) to make a deadline. However, Bertrand Meyer (and Steve McConnell and Barry Boehm) believe—based on empirical evidence—that judiciously adding people to a project can shorten its schedule.

You can shorten a schedule by adding more people...however there's a limit. You can only shorten the schedule for a software project by (up to) 25%. Since adding people to a software project means adding cost, what this is really saying is you can spend more to get your thing up to 25% more quickly. However, the reverse is not necessarily true. Sometimes you can take people off a project, give the remaining people more time, and get your thing for less money; sometimes you cannot.

This has been known for about 20 years and yet Brooks' Law has survived as a folk wisdom, and Bertrand Meyer wants to get the word out. That's why he wrote "In Search of the Shortest Possible Schedule."

I grew up on Brooks' Law, so I'm trying to absorb this. Brooks' Law seems right to me, and in "Brooks' Law Repealed?" Steve McConnell describes an experience that seems familiar:

To those of us who have been around the software-project block a few times, the claim feels true. We’ve participated on projects in which new people are brought on at the end. We know the irritation of having to answer questions from new staff when we’re already feeling overwhelmed about our own work. We’ve seen new hires make mistakes that set the whole project back. And we’ve experienced additional schedule slips even after staff has been added to a late project.

McConnell squares this experience with the new sans Brooks' Law world by pointing out Brooks' Law does apply in certain circumstances, but projects are poorly estimated and poorly tracked. The result is not knowing whether you are in the Brooks' Zone or whether there is enough project left for new hires to pay off the productivity lost to training them.

I'm not sure I buy that. I think the idea of estimation is fundamentally flawed. I can't help but feel like this is saying, "We're doing a bad job. Do better!" I'm more and more convinced that breaking work down, estimating the pieces, and rolling it back up is a terrible way to estimate. It fails to account for variability, and padding estimates is not the solution.

And sure, better project tracking seems like a good thing. It is a necessary first step, but having the data isn't enough, you also have to interpret and extrapolate it. Probably the best thing that can be done with tracking data is to let it empirically drive estimations.

I cannot deny the empirical evidence. You can pay more to shorten a project by up to 25%, but there are some intriguing questions that pop up: Why? Why 25%? Why doesn't it always work backwards? Could you repeat the process with a revised schedule and cut another 25%? How would knowing about this bias estimations?

I think what I take away from this is that Brooks' Law has narrower application than I initially expected and adding people to a project can bring it to completion more quickly.