Brooks's law

It was coined by Fred Brooks in his 1975 book The Mythical Man-Month.

This idea is known as Brooks' law, and is presented along with the second-system effect and advocacy of prototyping.

This is similar to the general law of diminishing returns in economics.

Another well-studied example is throwing more headcount at software development, yielding Brooks's law.

It was coined by Fred Brooks in his 1975 book The Mythical Man-Month.

This has since come to be known as Brooks's law.

Often, the death march will involve desperate attempts to right the course of the project by asking team members to work especially grueling hours (14-hour days, 7-day weeks, etc.) or by attempting to "throw (enough) bodies at the problem", often causing burnout.

Brooks's law is an observation about software project management according to which "adding manpower to a late software project makes it later".

Brooks's law is an observation about software project management according to which "adding manpower to a late software project makes it later".

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.

The modern practices of continuous integration, test-driven development, and iterative development significantly reduce the inter-developer communication overhead, and thus allow for better scalability.

The modern practices of continuous integration, test-driven development, and iterative development significantly reduce the inter-developer communication overhead, and thus allow for better scalability.

The modern practices of continuous integration, test-driven development, and iterative development significantly reduce the inter-developer communication overhead, and thus allow for better scalability.

Design patterns simplify the distribution of work, because the entire team can do its part within the framework provided by that pattern.

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.

This is the Bermuda plan, when 90% of the developers are removed ("send them to Bermuda") and the remaining 10% complete the software.