Brooks’ Law

In one of the classic works of software project management, “The Mythical Man Month: Essays on Software Engineering”, Fred Brooks first articulated what has now come to be known as “Brooks’ Law”:

Adding manpower to a late software project makes it later.

(Brooks 1975) Brooks attributes this phenomenon to two main factors. One is the fact that new people on the project take time to become productive, as there is a learning curve associated with introducing new team members. Regardless of a developer’s experience and depth of technical expertise, there is usually project-specific knowledge that is unlikely to be known to a new person. During this “ramp up” time the team is less productive as a whole. This is due not only to the initial low productivity of new team members, but is also due to the time that experienced team members must spend mentoring and coaching new staff, causing the experienced staff to be less productive themselves. The second factor has to do with the communication and coordination costs that increase as the team size grows.

In the context of our SD example model from the previous section, we can describe this effect by decomposing our Number of Developers into two stocks of Inexperienced Developers and Experienced Developers. Over time, Inexperienced Developers gain experience at a rate dictated by Time to Gain Experience. Also, we add a Hiring Rate and a Staff Departure Rate to incorporate the effect of people leaving and joining the project. This simple staffing model is depicted below in Figure 28.

Now, the other problem with simple project management models is that they employ non-dynamic values for Staff, and do not incorporate the effects of a dynamically changing staff composition on Productivity and FCC:

·         Staff (Number of Developers) often changes, especially on long-term programs. Moreover, not all developers are equal. Experience mix and learning curves play a part in how much “effective staff” are actually applied to the work.

·         Productivity is affected by the experience mix of the team.

·         The same is true for FCC, as a higher ratio of experienced to inexperience staff will lower defect generation.

Simple project models rely on a static, average, value of productivity, such as the 160 SLOC per person-month used in our example in section 4.2. Usually this is a historical measure of an organization’s performance on other projects. Let us improve this by extending the previous model to incorporate the effects of staff on project performance. A straightforward approach to this is modelled in Figure 29.

Relative Experience of New Staff represents the answer to “how experienced are new staff members compared to existing project staff members?” This can vary greatly from project to project, and organization to organization. For example a new developer on a Java project in the Air Traffic Control (ATC) domain may be a Java coding guru with years of experience, but be a new hire to the company and have no experience with ATC, the company culture, etc. For our modelling purposes, Relative Experience of New Staff is modelled as an exogenous variable.

Using this relative experience ratio we can formulate values for the Effect of Experience on Productivity and the Effect of Experience on FCC. The effect is based on the fraction of staff which are inexperienced and the Relative Experience of New Staff. Adding these effects in our model now shows how staffing dynamics affect controlling parameters of the rework cycle (Productivity and FCC.) Choosing a value of 20% for Relative Experience of New Staff, and ten new developers at the outset of the project, and zero experienced developers, we see the following model behaviour.

Figure 30 and Figure 31 show how Productivity and FCC suffer due to staff inexperience, but as developers gain experience and assimilate into the pool of experienced staff, the average productivity sees a marked improvement. These graphs plot the Effect of Experience on FCC, the number of New Staff¸ and the number of Experienced Staff to provide a visual indicator of improvement in FCC as the team composition evolves towards mostly experienced staff. Note that the Effect of Experience on FCC is a fraction, and modeled as a dimensionless unit (denoted “Dmnl” in these graphs). For example, an Effect of Experience on FCC of 1.05 means that this has a 5% improvement effect of FCC.

Our simple case so far assumes no staffing changes during the span of the project. However, in real projects (especially large-scale software engineering), staff churn is a reality that project management must fully consider as an integral part of the project system. Let us see what effect staff experience has on project completion time (Figure 32): It now takes about 22 months to complete all of Work To Do, for a project that “ideally” took five months to do back in Figure 23!

Now, let us see what happens when the management, at month number 16, decides to “rescue” the project by adding 5 more developers to the team. The results are shown in Figure 33. It now takes up to 24 month to complete.

Although a contrived example, this model illustrates the behavior behind Brooks’ law. The lesson for software project managers here is again to look for ways to improve FCC and Productivity – Adding staff late in the project simply makes things worse because it lowers productivity and increases defect generation, in aggregate. We can observe the effect of management’s hiring decision for example by comparing the graphs for Rework Generation Rate for both cases (with and without hiring at month 15). The comparison is shown in Figure 34. This extra rework, generated due to the addition of new staff, increases the amount of work that needs to be done for the project to complete.