Brooks' law
|
|
Adding manpower to a late software project makes it later.
Stated by Fred Brooks in his 1975 book The Mythical Man-Month. It is described well by John Drummond [1] (http://www.osopinion.com/Opinions/JohnDrummond/JohnDrummond1.html):
- "Brooks' Law states that programming work performed increases with direct proportion to the number of programmers (N), but the complexity of a project increases by the square of the number of programmers (N2). Therefore, it should follow that thousands of programmers working on a single project should become mired in a nightmare of human communication and version control."
Brooks' Law is often summarized as 'Nine women cannot have a baby in one month.'
A commonly understood implication of Brooks' 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 by a factor of ten between highly talented and efficient programmers and less talented programmers. However, Brooks' Law does not mean that starving a project of resources by employing fewer programmers beyond this point will get it done faster.
The other common way around the constraints of Brooks' 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 wrongly, 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.
Recently, it has been argued that the programming practices associated with open source software development may allow open source projects to appear to defy the predictions of Brooks' Law, by having extremely low communications costs which greatly increases the value of N at which communication costs become the bottleneck.
See also
External links
- Brooks' Law and open source: The more the merrier? (http://www-106.ibm.com/developerworks/linux/library/os-merrier.html)