Brooks's law

Last updated July 04, 2024

Brooks's law is an observation about software project management that "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, under certain conditions, an incremental person 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:

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.
Communication overhead increases 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.
Adding more people to a highly divisible task, such as cleaning rooms in a hotel, decreases the overall task duration (up to the point where additional workers get in each other's way). However, other tasks including many specialties in software projects are less divisible; Brooks points out this limited divisibility with another example: 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

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's law only 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 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.

An example of segmentation are design patterns that 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.

The Bermuda plan, where most developers on a project are removed ("sent to Bermuda") and the remaining are left to complete the software, has been suggested as a way of circumventing Brooks's law.^[12]^[13]

Notes

1 2 Frederick P. Brooks, Jr. The Mythical Man-Month . 1995 [1975]. Addison-Wesley.
↑ 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’s Law, which holds that adding people to a project slows it down."
↑ James Taylor, "A Survival Guide for Project Managers", 2nd edition, AMACOM ^{[ clarification needed ]}, 2006, ISBN 978-0814408773, p. 21.
↑ "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)
↑ "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)
↑ "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)
↑ "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)
↑ 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)
↑ "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)
↑ "The law assumes that all added labour 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)
↑ "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)
↑ Shea, Tom (7 May 1984). "Developers Unveil 'Vaporware'". InfoWorld. 6 (19). InfoWorld Media Group: 48. ISSN 0199-6649 . Retrieved 2010-04-13.
↑ Bruno, Eric J. (2023-02-06). "Curly Braces #9: Was Fred Brooks wrong about late software projects?". Java Magazine. Oracle Corporation.

Related Research Articles

Software engineering is an engineering approach to software development. A practitioner, called a software engineer, applies the engineering design process to develop software.

<i>The Mythical Man-Month</i> 1975 software engineering book by Fred Brooks

The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks first published in 1975, with subsequent editions in 1982 and 1995. Its central theme is that adding manpower to a software project that is behind schedule delays it even longer. This idea is known as Brooks's law, and is presented along with the second-system effect and advocacy of prototyping.

Collaborative software or groupware is application software designed to help people working on a common task to attain their goals. One of the earliest definitions of groupware is "intentional group processes plus software to support them."

In computer science, program optimization, code optimization, or software optimization is the process of modifying a software system to make some aspect of it work more efficiently or use fewer resources. In general, a computer program may be optimized so that it executes more rapidly, or to make it capable of operating with less memory storage or other resources, or draw less power.

The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly object-oriented programs. In its general form, the LoD is a specific case of loose coupling. The guideline was proposed by Ian Holland at Northeastern University towards the end of 1987, and the following three recommendations serve as a succinct summary:

Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.
Each unit should only talk to its friends; don't talk to strangers.
Only talk to your immediate friends.

Software development is the process used to create software. Programming and maintaining the source code is the central step of this process, but it also includes conceiving the project, evaluating its feasibility, analyzing the business requirements, software design, testing, to release. Software engineering, in addition to development, also includes project management, employee management, and other overhead functions. Software development may be sequential, in which each step is complete before the next begins, but iterative development methods where multiple steps can be executed at once and earlier steps can be revisited have also been devised to improve flexibility, efficiency, and scheduling.

The following outline is provided as an overview of and topical guide to software engineering:

Knowledge workers are workers whose main capital is knowledge. Examples include ICT Professionals, physicians, pharmacists, architects, engineers, scientists, design thinkers, public accountants, lawyers, editors, and academics, whose job is to "think for a living".

In software development, code reuse, also called software reuse, is the use of existing software, or software knowledge, to build new software, following the reusability principles.

The Software Peter principle is used in software engineering to describe a dying project which has become too complex to be understood even by its own developers.

Lean software development is a translation of lean manufacturing principles and practices to the software development domain. Adapted from the Toyota Production System, it is emerging with the support of a pro-lean subculture within the agile community. Lean offers a solid conceptual framework, values and principles, as well as good practices, derived from experience, that support agile organizations.

Automatic parallelization, also auto parallelization, or autoparallelization refers to converting sequential code into multi-threaded and/or vectorized code in order to use multiple processors simultaneously in a shared-memory multiprocessor (SMP) machine. Fully automatic parallelization of sequential programs is a challenge because it requires complex program analysis and the best approach may depend upon parameter values that are not known at compilation time.

Concurrent computing is a form of computing in which several computations are executed concurrently—during overlapping time periods—instead of sequentially—with one completing before the next starts.

In computer science, stream processing is a programming paradigm which views streams, or sequences of events in time, as the central input and output objects of computation. Stream processing encompasses dataflow programming, reactive programming, and distributed data processing. Stream processing systems aim to expose parallel processing for data streams and rely on streaming algorithms for efficient implementation. The software stack for these systems includes components such as programming models and query languages, for expressing computation; stream management systems, for distribution and scheduling; and hardware components for acceleration including floating-point units, graphics processing units, and field-programmable gate arrays.

Extreme programming (XP) is an agile software development methodology used to implement software systems. This article details the practices used in this methodology. Extreme programming has 12 practices, grouped into four areas, derived from the best practices of software engineering.

The open-source-software movement is a movement that supports the use of open-source licenses for some or all software, as part of the broader notion of open collaboration. The open-source movement was started to spread the concept/idea of open-source software.

A programming team is a team of people who develop or maintain computer software. They may be organised in numerous ways, but the egoless programming team and chief programmer team have been common structures.

Software construction is a software engineering discipline. It is the detailed creation of working meaningful software through a combination of coding, verification, unit testing, integration testing, and debugging. It is linked to all the other software engineering disciplines, most strongly to software design and software testing.

Extreme programming (XP) is a software development methodology intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent releases in short development cycles, intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

Distributed agile software development is a research area that considers the effects of applying the principles of agile software development to a globally distributed development setting, with the goal of overcoming challenges in projects which are geographically distributed.

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 page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[Brooks-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’s Law, which holds that adding people to a project slows it down."

[3] James Taylor, "A Survival Guide for Project Managers", 2nd edition, AMACOM ^{[ clarification needed ]}, 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 labour 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)

[shea1984-12] Shea, Tom (7 May 1984). "Developers Unveil 'Vaporware'". InfoWorld. 6 (19). InfoWorld Media Group: 48. ISSN 0199-6649 . Retrieved 2010-04-13.

[bruno20230206-13] Bruno, Eric J. (2023-02-06). "Curly Braces #9: Was Fred Brooks wrong about late software projects?". Java Magazine. Oracle Corporation.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]