العربية
中国
Français
Deutsch
Ελληνική
हिन्दी
Italiano
日本語
Português
Русский
EspañolBROOKS' LAW
'Brooks's law' was stated by Fred Brooks in his 1975 book ''The Mythical Man-Month'' as "Adding manpower to a late software project makes it later." Likewise, Brooks memorably stated "The bearing of a child takes nine months, no matter how many women are assigned." While Brooks's law is often quoted, the line before it in ''The Mythical Man-Month'' is almost never quoted: "Oversimplifying outrageously, we state Brooks's Law."
One reason for the seeming contradiction is that 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 typically must "ramp up" in this way with not only one, but multiple engineers who must educate the new worker in their area of expertise in the code base, day by day.
Another significant reason is the 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.
A commonly understood implication of Brooks's law is that it will be more productive to employ a smaller number of very talented (and highly paid) programmers on a project than to employ a larger number of less talented programmers, since individual programmer productivity can vary greatly between highly talented and efficient programmers and less talented programmers. However, Brooks's law does ''not'' mean that starving a project of resources by employing fewer programmers beyond a certain point will get it done faster.
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 determiners 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.
The programming practices associated with open source software development allow open source projects to defy the predictions of Brooks's law. See The Cathedral and the Bazaar by Eric Raymond.
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. For example, on a late construction project, one can employ additional dump trucks to haul refuse faster, without suffering the time penalty. The function of hauling refuse can be performed by anyone who possesses a minimal level of skill and a truck. Nothing differentiates one truck from the next, and no additional communication or training is required to commence the additional hauling. The requirement to get the new truck drivers up to speed is minimized and the resultant additional communications channels do not exist; truck drivers do not need to talk to other truck drivers in order to haul the refuse.
This is in sharp contrast to the typical work of software engineers, whose work is impacted both by the need to train and educate new workers, and by occasional mistakes that new workers are expected to make before they are fully familiar with the software project.
★ The Mythical Man-Month
★ The Cathedral and the Bazaar
★ Divide and conquer algorithm
★ Adages named after people
Ankur Malhotra
★ Brooks's Law repealed?
★ Exceptions to Brooks's Law
★ Brooks's Law and open source: The more the merrier?
| Contents |
| Explanations |
| Misconceptions |
| Possible solution |
| Open source software development |
| Application to other disciplines |
| See also |
| External links |
Explanations
One reason for the seeming contradiction is that 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 typically must "ramp up" in this way with not only one, but multiple engineers who must educate the new worker in their area of expertise in the code base, day by day.
Another significant reason is the 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.
Misconceptions
A commonly understood implication of Brooks's law is that it will be more productive to employ a smaller number of very talented (and highly paid) programmers on a project than to employ a larger number of less talented programmers, since individual programmer productivity can vary greatly between highly talented and efficient programmers and less talented programmers. However, Brooks's law does ''not'' mean that starving a project of resources by employing fewer programmers beyond a certain point will get it done faster.
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 determiners 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.
Open source software development
The programming practices associated with open source software development allow open source projects to defy the predictions of Brooks's law. See The Cathedral and the Bazaar by Eric Raymond.
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. For example, on a late construction project, one can employ additional dump trucks to haul refuse faster, without suffering the time penalty. The function of hauling refuse can be performed by anyone who possesses a minimal level of skill and a truck. Nothing differentiates one truck from the next, and no additional communication or training is required to commence the additional hauling. The requirement to get the new truck drivers up to speed is minimized and the resultant additional communications channels do not exist; truck drivers do not need to talk to other truck drivers in order to haul the refuse.
This is in sharp contrast to the typical work of software engineers, whose work is impacted both by the need to train and educate new workers, and by occasional mistakes that new workers are expected to make before they are fully familiar with the software project.
See also
★ The Mythical Man-Month
★ The Cathedral and the Bazaar
★ Divide and conquer algorithm
★ Adages named after people
Ankur Malhotra
External links
★ Brooks's Law repealed?
★ Exceptions to Brooks's Law
★ Brooks's Law and open source: The more the merrier?
This article provided by Wikipedia. To edit the contents of this article, click here for original source.
psst.. try this: add to faves
