Brooks's law

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Brooks's law is a principle in software development which says that "adding manpower to a late software project makes it later".[1] It was coined by Fred Brooks in his 1975 book The Mythical Man-Month.

Contents

[edit] Explanations

According to Brooks himself, the law is an "outrageous oversimplification",[1] but it captures the general rule. Brooks points to two 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 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.
  2. Communication overheads increase as the number of people increase. 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.

[edit] 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.[2][3]

The first point is to note that Brooks's Law applies to projects that are already late.[4] Projects can be brought back into (or kept into) control if people are added earlier in the process.[5] It's 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.[6]

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.[7] Good programmers or specialists can be added with less overhead for training.[8] People can be added to do other tasks related with the project, for example, QA or documentation; given that the task is clear, ramp up time is minimized.[9]

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.

[edit] 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 QA, using cheap communication channels (such as email) to coordinate the work. Such projects scale well, despite 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;[10]
  • Efficient parallelization of work, reducing the communication overhead;[11]
  • A social context where the contributors are voluntary, associated with a leadership style that does not use coercion;[12]
  • Less reliance on traditional management methods to reduce duplication efforts.[13]

[edit] See also

[edit] Notes

  1. ^ a b Frederick P. Brooks, Jr. "The Mythical Man Month". 1995. Addison-Wesley.
  2. ^ "In spite of Brooks’ 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)
  3. ^ "The trouble is that there are important exceptions that many people don’t take the time to consider when using Brooks’s law to justify something". (Berkun, 2006)
  4. ^ "Implicit in Brooks’ Law 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?" (McConnel, 1999)
  5. ^ "We have found that adding people to a late project will always increase its cost, but the project may not always be late. Only under certain degree of sequential constraints among project tasks will the project be delayed." (Hsia, Hsu, Kung, 1999)
  6. ^ 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’ Law. It’s a result of underestimating the project in the first place." (McConnell, 1999)
  7. ^ "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)
  8. ^ "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)
  9. ^ "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)
  10. ^ "There are still more reasons that source-code–level bug reporting tends to be very efficient. They center around the fact that a single error can often have multiple possible symptoms, manifesting differently depending on details of the user's usage pattern and environment. ... On the other hand, suppose many people are trying trace paths in parallel while doing rapid releases. Then it is likely one of them will find the easiest path immediately, and nail the bug in a much shorter time." (Eric S. Raymond, 1999, "How Many Eyeballs Tame Complexity")
  11. ^ "But on open-source projects, the halo developers work on what are in effect separable parallel subtasks and interact with each other very little; code changes and bug reports stream through the core group, and only within that small core group do we pay the full Brooksian overhead" (Eric S. Raymond, 1999, "How Many Eyeballs Tame Complexity")
  12. ^ "19: Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one." (Eric S. Raymond, 1999, "The Social Context of Open-Source")
  13. ^ "John Hasler has suggested an interesting explanation for the fact that duplication of effort doesn't seem to be a net drag on open-source development. He proposes what I'll dub Hasler's Law: the costs of duplicated work tend to scale sub-qadratically (sic) with team size—that is, more slowly than the planning and management overhead that would be needed to eliminate them." (Eric S. Raymond, 1999, "Notes")

[edit] References

Retrieved from "http://en.wikipedia.org/wiki/Brooks%27s_law"
Personal tools