Brooks's law

Brooks' law is a claim about software project management according to which "adding manpower to a late software project makes it later". It was coined by Fred Brooks in his 1975 book The Mythical Man-Month. According to Brooks, there is an incremental person who, when added to a project, makes it take more, not less time.

According to Brooks himself, the law is an "outrageous oversimplification", but it captures the general rule. Brooks points to the main factors that explain why it works this way:

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.

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

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. 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.

Good management and development practices also help to minimize the impact of Brooks's law. 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. 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.

...
Wikipedia