Brooks' Law

Brooks’ Law is indeed one of the, if not the most widely discussed topic from Frederick P. Brooks, Jr.’s work on software engineering, Mythical Man Month:

Adding manpower to a late software project makes it later — Fred Brooks

Software projects are complex, and new workers must have the knowledge of the work that has be completed till the time they were introduced to the project. This requires the current project team to diminish their productivity temporarily in order for the new team to catch up. Another reason of the delay being the communication overheads that increase with the increase in the number of people involved in a certain project. Brooks has presented detailed analysis in support for establishing Brooks' Law, and this law does have a major role to play in Software Project Management.

Brooks' basic model, which he described 20 years later as less than ideal, is called the waterfall model or Big Design Up Front (BDUF). Attempting to design all functionality at the beginning is less than ideal; the Pareto principle appears to be as true in software engineering as in the original use in economics: 20% of the functionality will cover 80% of users' needs. The challenge is picking the right 20%, which may need a good deal of user interaction, possibly with prototypes. A variant on Pareto is that the last 20% of functionality is apt to require 80% of the software development effort.

Examples

There has been a lot of study on Brooks Law since 1975, the year when the Mythical Man Month was published. In most of the cases, it has been found that Brooks Law holds quite strongly in Software Development.

Apple Aperture

An example of the same was the development of Apple Aperture. The product team of Aperture grew to 150 people from the original 20 in just a few weeks, comprising about 100 software engineers, 40 QA people, and the remaining managers. Not surprisingly, this is precisely when things went from bad to worse with regard to the quality of the product. The 130 additional members were not and were never meant to be permanent members of the Aperture team — they were borrowed talent from another “Pro app” product teams and were added during the homestretch of the Aperture 1.0 development cycle in an ill-considered effort to ship faster. This was termed as the Mythical Man Month disaster.

Possible Solutions

As mentioned earlier, there has been an extensive amount of study on Brooks law in the past thirty three years in order to find possible solutions to the law or finding a way around the constraints mentioned and coming up with an efficient way to speed up processing of an already late project so that it can be delivered on time.

A possible solution, as mentioned on Wikipedia 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. This can make the problem worse, not better, in case it is not applied correctly, by impeding communication between programmers working on parts of the project which are closely coupled. Three other possible solutions for Brooks’ law which involve modifications in the architecture of the project, the social and political aspects of the work climate and modern practices such as continuous integration, test first design etc.

Adding people late to a project will always increase its cost, but the project may not always be late. If we put certain constraints on how and when the additional workforce is added, we can still achieve a target on time or with minimal delays. If we consider the timeline of a software project and analyze all the resources properly, then we can say that there is a certain time T on the timeline until which the addition of workforce will not over delay a certain software project. This will be a time that can be considered to be a threshold for Brooks Law. Beyond the time T on the timeline, the addition of workforce will definitely delay the project completion. This is a slight modification to Brooks Law, but if we determine the time T accurately on the timeline, this revised principle will be a useful guiding principle which will benefit software development.

Exceptions

A law that has had such a strong hold on such a wide, continuously developing field of software engineering for such a long time does carry a lot of weight in terms of application. But there have been cases, although less in number where the addition of workforce helped in speeding up the delivery of a delayed project. An example of the same is that of the Apple iPhone, where a large number of developers were added from Leopard OS project to the iPhone team because the delivery of the iPhone was getting delayed. Highly trained professionals from the Leopard OS team were chosen to work on the iPhone’s software and QA issues which helped in speeding up the delivery of the product. The launch date of the iPhone was postponed, but for a shorter span of 15 days in comparison to the original anticipated delay of one to two months. This obviously delayed the release date of the Leopard operating system, but the speed up the development of the iPhone was evident. From this example, we can notice the fact that addition of highly trained, experienced individuals to the workforce of a delayed project can help in speeding things up. This comes at a cost, but if a company can afford the same, it would be worth every extra penny to bring out the product in the market on time. What this suggests is that there may be ways, which may help an organization in conquering Brooks' law. This might not be applicable in all the cases. But, even if it applies to a limited number of cases, it should be considered to be highly beneficial.

New paradigms: Agile programming

An alternative range of techniques, principally having different rapid prototyping and incremental development in common, share the principles of the Agile Manifesto.

Extreme Programming

Extreme programming is a one Agile methodology. Many practices of Extreme programming (XP) can help teams to overcome the Brooks’ Law and actually increase production by adding resources. There are pros and cons of extreme programming, but if software development teams demonstrate this phenomenon, then it can be considered beneficial for a number of other projects as well. Extreme Programming is a based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation. Practicing XP techniques to reduce the negative impact of challenges faced by increase of team size (which leads to Brooks law). Extreme programming practices like collective code ownership, test driven implementation, team co location, pair programming, collective code ownership etc. help in overcoming the challenges for new developers like code ownership issues, changes in code creating faults somewhere else, quick communication between team members, help from experienced people and avoiding too much of extra work respectively. If we consider an example of an XP team of four people working in pairs on a project with 100% efficiency and say they complete a job of 2 x (2 x 100) = 400 units. If the team size is doubled and each new individual is associated with an experienced team member so that a new team pair now comprises of one new member and one experienced member, it is noted that the experienced member still works well, and practicing XP techniques, the new member fits into the team with little difficulty. It is obvious that there will be performance degradation. Say, the new team now works at 60% efficiency on an average. Still the total number of units produces by the new 4 teams will be 4 x (2 x 60) = 480 units. And if XP techniques are applied with more perfection and even if the new teams works at a minimal increase in efficiency of 63%, the new units of work done will be 4 x (2 x 63) = 504 units. What we see here is an observation that goes against the Brooks’ Law. It is easier said than done. While this programming technique looks good on paper, there will certainly be difficulties in implementing the same efficiently, and all XP teams might not be able to give this amount of efficiency. But still, there is a chance that these techniques defy Brooks’ Law and benefit Software engineering.

Conclusion

In conclusion, it can be said that Brooks’ Law is undoubtedly one of the biggest things to be kept mind by a manager of a software development team whenever he is put in a situation of managing a project that is late. But, there have been and will possibly be exceptions to the Brooks’ Law. A law that has been in place for over thirty years is something that should never be ignored. But as they say, necessity is the mother of all inventions, and when it becomes necessary for a project manager to complete his project on time and increasing the team size seems to be his only option, one might come up with a solution that defies Brooks Law for good. There may exist partial ways around the Brooks law, but till date there has been no definite way that overcomes the law completely.