Brooks's law

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.

Explanations

According to Fred Brooks himself, the law is a "outrageous oversimplification", but it's valid in the sense that it captures the general rule. Brooks points two main factors why it works this way:

1. It takes some time for the people added to a project to become productive. Brooks call this the "ramp up" time. Software projects are complex engineering endeavors, and new workers on the project must first become educated in the work that has preceded them; this education requires diverting the 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 can even have negative contributions (for example if they introduce bugs which move the project further away from completion).
2. Communication overheads increase as the number of people increase. The number of different communication channels goes up as the square of the number of people; double the number of people and you get four times as many different conversations. Everyone working on the same thing needs to keep in sync, so as you add more and more people, they spend more and more time trying to find out and keep up with what everyone else is doing.

Possible solution

The common way around the constraints of Brooks's law is to segment the problem into smaller sub-problems, each of which can then be solved by a smaller team, and to have a top-level team that is responsible for systems integration. However, this method relies on the segmentation of the problem being correct 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.

Architecture provides another component of a solution to Brooks's law. When the software application is designed around a stable design pattern, then the rest of the programming team(s) can work within the framework of that pattern. The design pattern defines the rules that the programmers follow and provides consistency and scale-ability. Brooks's law, however, still applies when building out the components of the design pattern or the development framework.

Some authors (see Creating a Software Engineering Culture by Karl E. Weigers, for example) 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, Weigers 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.

A partial solution being actively practiced today involves the modern practices of continuous integration, test first design, and iterative development which significantly reduce and centralize any necessary inter-developer communication.

Brooks's Law and Open source software development

Compared with traditional software development, open source projects follow a different methodology (see The Cathedral and the Bazaar). Large scale open source projects leverage the power of vast amount of participants which take care of coding and Q&A, using cheap communication channels (such as email) to coordinate the work. Such projects scale well, despite of Brooks's Law, due to several reasons:

• Concepts such as "manpower" as a measurement of team size, or the need of a strict delivery schedule, are either very hard to apply, or are applied in a different way in open source projects, making a direct application of Brooks's Law impossible;
• Large scale open source projects have the ability to leverage the large number of testers to find bugs faster (also known as Linus's Law);
• Testers can read and analyze the source code, helping developers to track down bugs more efficiently ;
• Efficient parallelization of work, reducing the communication overhead;
• A social context where the contributors are voluntary, associated with a leadership style that does not use coercion.;
• Less reliance on traditional management methods to reduce duplication efforts.

Application to other disciplines

Brooks's law's applicability to other disciplines varies depending upon the nature of the work. In any area where the work products are commodities, the law does not apply.

See also

• List of software development philosophies
• The Cathedral and the Bazaar
• Divide and conquer algorithm
• Adages named after people

External links

• Brooks's Law repealed?
• Exceptions to Brooks's Law
• Brooks's Law and open source: The more the merrier?