Brooks Law Is Applicable To Many Collaborative People Activities

brooks law 2 unaccomplished workBrooks Law is that there is an incremental person, when added to a software project, that makes it require more, not less time. And adding people to a late software project makes it later.

 I have been spouting Brooks Law for over 20 years for software projects.  You know the drill.  An important project is late.  So the first inclination is to add more people, or put in a red team, or something to speed it up.  Unfortunately when Brooks Law comes into play, those additional people make the project fall further behind.  What happens is that for each additional person, there is some energy lost as they need to communicate with others.  At some point the project has all the people it can handle.  And adding people makes the project later. Even if the project could absorb more people, the reduction in productivity as the in-place team has to communicate with the  additional staff on the late project causes the late project to get later.

Using this information we can determine where Brooks Law might kick in at any point in the project and can compute the minimum time – the point at which people have been added at the maximum rate that is still productive, and hence a minimum staffing time and numbers of staff.  We can also determine the inefficiencies of overstaffing and the schedule penalty / cost improvement from using an optimal effort schedule as well. This is one of the core models within SEER for Software (SEER-SEM).

Although I have generally discussed this phenomenon in software projects, the same applies to hardware, IT or other engineering projects.  And even on assembly projects.

I recall working at a cannery one evening.  This was a facility that canned food for the needy.  We had a great turnout, probably over a hundred people anxious to help.  As the peaches came down the conveyor belt, the main job was to cut off any bad parts.  Each person, wanting to help, picked up all the peaches they could and cut something off.  I am sure the net pounds of peaches canned was well below what it would have been with the right number of people on the line.

And hardware development projects have nearly the same issues as software projects.  Add too many people too early and there will be wasted energy.  The project can take longer.

The opposite is also true, to a point.  Assuming a project is planned with a longer schedule and fewer people from the start: Fewer people on a project can extend the schedule but fewer communication paths cause the total effort to be less.

The basic issue of Brooks Law can be expressed in the equation:

n(n − 1) / 2

This equation computes how many different  communication paths exist between team members. Thus the larger the team, the more time people spend communicating rather than making progress.  So adding people to a project that is already late increases those communication paths and takes more of the time of those who should be making progress.

 brooks law slide 1 min time

Figure 2 illustrates that there is a minimum time for any software project to be completed (it can be shipped sooner but to be really ready to ship this minimum time comes into play.)  Additionally, some cost maybe saved by a planned longer schedule (but not many projects in the US are willing to wait longer… In general, Europe is much more appreciative of the lower cost opportunities.) up to the optimal effort point where the cost begins to rise again.

PS: Use caution when some claim Brooks law is no longer valid. Proper application of Brooks law should look at individual teams working on individual programs, not an entire large system all at once.

References:

Excellent Knol on Brooks law.

The Mythical Man Month” is a classic in software engineering, written by Frederick Brooks and describes Brooks Law in detail.

Wikipedia, The Mythical Man Month

Software Sizing, Estimation and Risk Management: when Performance Is Measured Performance Improves”  by D. Galorath and M. Evans.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.

Comments

2 Responses to “Brooks Law Is Applicable To Many Collaborative People Activities”

  1. Nexus on June 16th, 2010 5:20 am

    Ive just come across this and it is not surprising that you would see productivity falls and complexity rise in human social groups. We do not using humans to code any aspect of the product we have built. In fact the whole application is auto generated from an engineering specification so Brooks Law does not apply as each additional human designer (not programmer as there are none) adds to the productivity and reduces cost as labour our development costs are zeroed. Now that we use this very productive tool set and methodology we would never use a hand crafted approach again.

  2. galorath on June 28th, 2010 5:27 pm

    Thanks for the comment. You are likely seeing seeing some entropy when the teams of designers get larger than a couple people. If it is only one or two humans doing the work then there you will not. But that is great that you are being so productive.

Leave a Reply

You must be logged in to post a comment.