Brooks’ law

Brooks' law is a claim about software project management according to which "adding manpower to a late software project makes it later".[1][2] It was coined by Fred Brooks in his 1975 book The Mythical Man-Month. According to Brooks, there is an incremental person who, when added to a project, makes it take more, not less time.

Explanations

According to Brooks himself, the law is an "outrageous oversimplification",[1] but it captures the general rule. Brooks points to the main factors that explain why it works this way:

  1. It takes some time for the people added to a project to become productive. Brooks calls this the "ramp up" time. Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them; this education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully. Each new worker also needs to integrate with a team composed of several engineers who must educate the new worker in their area of expertise in the code base, day by day. In addition to reducing the contribution of experienced workers (because of the need to train), new workers may even make negative contributions, for example, if they introduce bugs that move the project further from completion.
  2. Communication overheads increase as the number of people increases. Due to combinatorial explosion, the number of different communication channels increases rapidly with the number of people.[3] Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing.
  3. Limited divisibility of tasks. Adding more people to a highly divisible task such as reaping a field by hand decreases the overall task duration (up to the point where additional workers get in each others way). Some tasks are less divisible; Brooks points out that while it takes one woman nine months to make one baby, "nine women can't make a baby in one month".

Exceptions and possible solutions

Brooks' law is often cited to justify why projects keep being late, despite management efforts. However, there are some key points in Brooks's law that allow exceptions and open the door for possible solutions.[4][5]

The first point is to note that Brooks' law often applies to projects that are already late.[6] Projects can be brought back into (or kept in) control if people are added earlier in the process.[7] It is also important to determine if the project is really late, or if the schedule was originally overly optimistic. Scheduling mistakes account for a large number of late projects. Correcting the schedule is the best way to have a meaningful and reliable time frame for the project's completion.[8]

The quantity, quality and role of the people added to the project also must be taken into consideration. One simple way to circumvent the law on an overrun project is to add more people than needed, in such a way that the extra capacity compensates the training and communication overhead.[9] Good programmers or specialists can be added with less overhead for training.[10] People can be added to do other tasks related with the project, for example, quality assurance or documentation; given that the task is clear, ramp up time is minimized.[11]

Good management and development practices also help to minimize the impact of Brooks' law. The modern practices of continuous integration, test-driven development, and iterative development significantly reduce the inter-developer communication overhead, and thus allow for better scalability.[12] New tools for software development and documentation also help to minimize the ramp up time, making it simpler for new programmers to get involved in the work. Design patterns simplify the distribution of work, because the entire team can do its part within the framework provided by that pattern. The design pattern defines the rules that the programmers follow, simplifies communication through the use of a standard language, and provides consistency and scalability. Finally, good segmentation helps by minimizing the communication overhead between team members. Smaller sub-problems are solved by a smaller team, and a top-level team is responsible for systems integration. For this method to work, the segmentation of the problem must be done correctly in the first place; if done incorrectly, this can make the problem worse, not better, by impeding communication between programmers working on parts of the problem which are actually closely coupled, even when the project plan has decreed that they are not.

Some authors – see, for example, Creating a Software Engineering Culture by Karl E. Wiegers – have stressed the importance of the social and political aspects of the work climate as determinants of the effectiveness of individual programmers and the project team as a whole. Rather than depending on heroes to carry the day with extraordinary efforts, Wiegers argues that a team of ordinarily-skilled individuals can repeatedly deliver timely results in the right work environment. Efforts to improve the effectiveness of teams can ameliorate, if not eliminate, the consequences of Brooks' law.

Eric S. Raymond mentions this in The Cathedral and the Bazaar. He notes that the number of one-to-one communications channels between N developers scales with N^2. Ergo, adding a new developer, assuming zero time spent "ramping up" (getting familiar with the project and its existing participants), can easily result in productivity diminishing with increased numbers of developers. He posits that part of why the Open Source development model has been able to scale so well is that the "release early, release often" principle is effectively a form of broadcast communications: lots of small, incremental releases provide a one-to-many communications channel that eliminates the need for many of the one-to-one channels that form the slowdown in Brooks' Law. Instead of having a discussion with multiple other programmers about the correct mechanism to resolve a particular problem, code it and throw it out there for all to see. If someone else has a better way of solving the problem, they are welcome to improve the code. In the meantime, as various features are added and function in a satisfactory manner, other programmers will see these as "solved problems" and focus their attention elsewhere.

See also

Notes

  1. 1 2 Frederick P. Brooks, Jr. The Mythical Man-Month. 1995 [1975]. Addison-Wesley.
  2. ↑ Maggie Fox NBC News, October 21, 2013, Better use the phone: Why Obamacare website is such a fail. Accessed Oct 21, 2013. "And sending in too many of the "best and the brightest’ might not be the right fix, either, software experts note. They often cite Brooks’ Law, which holds that adding people to a project slows it down."
  3. ↑ James Taylor, "A Survival Guide for Project Managers", 2nd edition, AMACOM , 2006, ISBN 978-0814408773, p. 21.
  4. ↑ "In spite of Brooks's law, adding people to a late project remains commonplace" ... "I have evangelized this well-worn software engineering chestnut many times myself, but I no longer think it's true". (McConnell, 1999)
  5. ↑ "The trouble is that there are important exceptions that many people do not take the time to consider when using Brooks's law to justify something". (Berkun, 2006)
  6. ↑ "Implicit in those projects is that it applies only to the final phases of a project. The question is, How do you know whether you're in a project's final phases?" (McConnell, 1999)
  7. ↑ "We have found that adding people to a late project will always increase its cost, but the project may not always be late since there may be sufficient schedule to absorb them and the project may not be at maximum staffing. Only under certain degree of sequential constraints among project tasks will the project be delayed." (Hsia, Hsu, Kung, 1999)
  8. ↑ Late chaotic projects are likely to be much later than the project manager thinks – project completion isn't three weeks away, it's six months away. Go ahead and add staff. You'll have time for them to become productive. Your project will still be later than your plan, but that's not a result of Brooks's law. It's a result of underestimating the project in the first place." (McConnell, 1999)
  9. ↑ "Gordon and Lamb studied Brooks's law and suggested that the best way to recover from a slipping schedule is to add more people than might be expected to be necessary, and to add them early." (Hsia, Hsu, Kung, 1999)
  10. ↑ "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." (Berkun, 2006)
  11. ↑ "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." (Berkun, 2006)
  12. ↑ Bakal, Martin R.; Althouse, Jennifer; Verma, Paridhi (14 August 2012). "Continuous integration in agile development: How agile methods, continuous integration, and test-driven enhance design and development of complex systems". IBM developerWorks. Retrieved 25 September 2015.

References

  • Steve McConnell. "Brooks' Law Repealed," IEEE Software, vol. 16, no. 6, pp. 6–8, Nov/Dec, 1999. Also available at the authors website (Brooks's law repealed?).
  • Pei Hsia, Chih-tung Hsu, David C. Kung. "Brooks's law Revisited: A System Dynamics Approach," compsac, p. 370, Twenty-Third Annual International Computer Software and Applications Conference, 1999.
  • R. L. Gordon and J. C. Lamb. "A Close Look at Brooks' Law," Datamation, June 977, pp. 81–86.
  • Berkun, Scott (January 11, 2006). "Exceptions to Brooks' Law". Retrieved 2008-07-28. 
  • Brooks law Is Applicable To Many Collaborative People Activities
This article is issued from Wikipedia - version of the Saturday, December 05, 2015. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.