Brooks' law
Encyclopedia
Brooks's law is a principle in software development
which says that "adding manpower to a late software project makes it later". It was coined by Fred Brooks
in his 1975 book The Mythical Man-Month
. The corollary
of Brooks's Law is that there is an incremental person who, when added to a project, makes it take more, not less time. Brooks adds that "Nine women can't make a baby in one month".
The first point is to note that Brooks's Law often applies to projects that are already late. Projects can be brought back into (or kept in) control if people are added earlier in the process. 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.
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. Good programmers or specialists can be added with less overhead for training. 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.
Good management and development practices also help to minimize the impact of Brooks's Law. The modern practices of continuous integration
, test first design
, and iterative development significantly reduce the inter-developer communication overhead, and thus allow for better scalability. 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's law.
Software development
Software development is the development of a software product...
which says that "adding manpower to a late software project makes it later". It was coined by Fred Brooks
Fred Brooks
Frederick Phillips Brooks, Jr. is a software engineer and computer scientist, best known for managing the development of IBM's System/360 family of computers and the OS/360 software support package, then later writing candidly about the process in his seminal book The Mythical Man-Month...
in his 1975 book The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks, whose central theme is that "adding manpower to a late software project makes it later"...
. The corollary
Corollary
A corollary is a statement that follows readily from a previous statement.In mathematics a corollary typically follows a theorem. The use of the term corollary, rather than proposition or theorem, is intrinsically subjective...
of Brooks's Law is that there is an incremental person who, when added to a project, makes it take more, not less time. Brooks adds that "Nine women can't make a baby in one month".
Explanations
According to Brooks himself, the law is an "outrageous oversimplification", but it captures the general rule. Brooks points to two 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 engineeringEngineeringEngineering is the discipline, art, skill and profession of acquiring and applying scientific, mathematical, economic, social, and practical knowledge, in order to design and build structures, machines, devices, systems, materials and processes that safely realize improvements to the lives of...
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 multiple 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 have negative contributions – for example, if they introduce bugs that move the project further from completion. - Communication overheads increase as the number of people increases. The number of different communication channels increases along with the square of the number of people; doubling the number of people results in four times as many different conversations. 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.
Exceptions and possible solutions
Brooks's 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.The first point is to note that Brooks's Law often applies to projects that are already late. Projects can be brought back into (or kept in) control if people are added earlier in the process. 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.
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. Good programmers or specialists can be added with less overhead for training. 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.
Good management and development practices also help to minimize the impact of Brooks's Law. The modern practices of continuous integration
Continuous integration
In software engineering, continuous integration implements continuous processes of applying quality control — small pieces of effort, applied frequently...
, test first design
Test-driven development
Test-driven development is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new...
, and iterative development significantly reduce the inter-developer communication overhead, and thus allow for better scalability. 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
Design pattern (computer science)
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem 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. 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
Communication
Communication is the activity of conveying meaningful information. Communication requires a sender, a message, and an intended recipient, although the receiver need not be present or aware of the sender's intent to communicate at the time of communication; thus communication can occur across vast...
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's law.
Open source software development
While open source projects rarely have schedules, nonetheless they can reach a state in which they are called "late" by their sponsors, participants, and users. In such a case, Brooks's law ("adding manpower to a late software project makes it later") surely applies, for exactly the reasons that Brooks enumerates: time for the new developers to become productive and increased communication overhead. In addition, unless there are strict controls, newcomers may reduce the productivity of experienced developers by checking in buggy or inappropriate changes, which then have to be backed out.See also
- Death marchDeath march (software development)In project management, a death march is any of several types of pathologic projects involving a dysphemistic, dark-humor analogy to real death marches, such as being gruelingly overworked, and being gruelingly overworked for ill-founded reasons on a project that is obviously at high risk of bad...
- Anti-patternAnti-patternIn software engineering, an anti-pattern is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.The term was coined in 1995 by Andrew Koenig,...
- List of eponymous laws
- List of software development philosophies