Brooks Law states: “Adding manpower to a late software project makes it later.” This Law is applicable to any task involving lots of people in complex interaction. The only evidence Brooks provides is anecdotal: “Since software construction is complex, the communications overhead is great.” Furthermore, his graph illustrating the perverse “bathtub” relationship between men and months has axes with no numbers on them. No one seriously doubts the general validity of Brooks strange graph but there is something disturbing about a Law that lacks quantification and has no coherent theory to explain why it must be so. This Knol provides a scientific underpinning, derived from Information and Hierarchy Theory, that allows quantification of Brooks Law. Given this theoretical support, it may be possible to determine when adding more software engineers to a project is likely to delay completion rather than speed it.
Brooks Law states:
Adding manpower to a late software projectmakes it later.
This Law is applicable to any task involving lots of people in complex interaction, not just software engineering.
This famous remark by Fredrick P. Brooks, Jr. in his classic book
The Mythical Man-Month[Brooks, 1975] is, unfortunately, lacking in scientific rigor. The only evidence he provides is anecdotal:
Since software construction is complex, the communications overhead is great.
Furthermore, his graph (see his “Fig. 3.” above) illustrating the perverse “bathtub” relationship between “men”  and months has axes with no numbers on them.
Never the less, this bit of wisdom has stood the test of time for over three decades. It has done so in the face of software’s new status as an engineering discipline.Despite the advent of higher-level languages, integrated programming environments, object-oriented approaches, and capability maturity models, no one with experience in software engineering for complex systems seriously doubts the general validity of Brooks strange graph.
However, there is something disturbing about a
Lawthat lacks quantification and has no coherent theory to explain why it must be so. This paper provides a scientific underpinning, derived fromInformationandHierarchy Theory,that allows quantification of Brooks’ Law. Given this theoretical support, it may be possible to determine when adding more software engineers to a project is likely to delay completion rather than speed it.
According to Fredrick P. Brooks, Jr. [Dorfman, 1997, p351]:
…the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth… Men and months are interchangeable commodities only when a task can be partitioned among many workers withno communication among them.[Italicsin original]
Brooksprovides a graph to illustrate the above point (see his “Fig. 1.” at right).Note that there areno numbers on the axes for “Men” and “Months”. He states his rationale as follows:
The term “man-month” implies that if one man takes 10 months to do a job, 10 men can do it in one month. This may be true of picking cotton.
The best that can be done when worker training and intercommunication is required is a diminishing results trade between men and months (see Brooks “Fig. 2.” at right).He states his rationale as follows:
Even on tasks that can be nicely partitioned among peoiple, the additional communication required adds to the total work, increasing the schedule.
For the case of software development, the situation may be even worse than indicated in thefigure to the right. The inherent complexity of software, and the need for continual intercommunication between workers, may lead to the situationwhere addition of more workers may, according to Brooks Law, actually lengthen the schedule!
What is the scientific basis for the perverse “bathtub” curve (see Brooks “Fig. 3.” above in the Abstract section).
Quantifying Brooks Curves
How may we add scientific rigor, quantification, and a coherent theoretical underpinning for
Brooks Law? What mathematical equations may be utilized to generate Brooks strange “bathtub” curve? This section quantifies Brooks three curves.
From here on,Brooks obsolete terminology will be updated, using “people” instead of “men”in recognition of the fact software engineers are at least as likely to be women as men.
The figure below shows the results of analysis based on combining the
Law of Diminishing Returnsand theOptimal Span Hypothesis.While not identical, the upper graph is a “bathtub” similar to Brooks “Fig. 3.” and it is quantified. The figure also includes two other quantified curves, the middle curve is similar to Brooks “Fig 2.” (theLaw of Diminishing Returns)and the lower curve similar to Brooks “Fig. 1.” (“Men and months are interchangeable”)The section that follows provides the equations and rationale used to generate the quantified results presented here.
1.InterchangeablePeople and Months
Brooks “Fig. 1.” where people and months are interchangeableis quite easy to quantify.
If one person produces one unit of work in one unit of time, ten peoplewill produce ten units of work in one unit of time. The work produced by
Ppeople in parallel in one unit of time will be:
See the lower curve in the figure above for a quantified version of Brooks “Fig. 1.” for a100 MMM project.
2. Law of Diminishing Returns
Brooks “Fig. 2″is also easy to quantify using the well-known
Law of Diminishing Returns.This law is based on the well-known fact that adding peoplein parallel seldom increases the work performed in direct proportion to the number of people. In general, if one person produces one unit of work in a unit of time, the work produced byPpeoplein parallel in one unit of time will be:
W =P f(2)
f = ½ = 0.5(square-root) is a commonly used value. Brooks gives a version of this relationship, namely that the number of man-months to complete a software project is proportional to “complexity” raised to the power of 1.5 (equivalent to the case wheref = 1/1.5 = 0.667). Brooks assumes that what he calls “complexity” is proportional to code size. Since Brooks gives no mathematical justification for his use of the “power of 1.5”, I will use the more traditional square root “power of 2” value in this Knol.
f = 0.5, the result is thatP = 2peoplein parallel will not double the productivity, but merely do aboutW = 1.4units of work in timet. To double the productivity and increase the amount of work toW = 2units will require adding about3people(for a total ofP = 4). To further increase the amount of work toW = 3units will require adding another5people(for a total ofP = 9).
Complex projects arealmost always performed by a department where one person, the manager, does no direct productive work on the project. Therefore we must subtract
1from the number of people assigned and the work produced byPpeoplein parallel in one unit of time will be:
W =(P-1) f(2a)
See the lower curve in the figure above for a quantified version of Brooks “Fig. 2.” for a 100 MMM project.
As discouraging as the curves corresponding to Brooks’ Figure 2 may be, the amount of work continues to increase as peopleare added, but at a diminishing rate. This falls short of the situation represented by Brooks Law”bathtub” curve where, after a certain point, an increase in peopleresults in an increase in months rather than a decrease. Therefore, the Law of Diminishing Returns, in and of itself, no matter how low the value for
f, does not and can not theoretically justify Brooks Law.
3. Optimal Span Hypothesis YieldsBrooks’ “Bathtub” Curve
How may we quantify Brooks “Fig. 3.”?The answer is to multiply the effect of the
Law of Diminishing Returnsby the effect of theOptimal Span Hypothesis(OSH)for a 100 MMM project, whichyieldsthe top curve in the abovefigure that is somewhat similarto Brook’s “bathtub curve”.
In general, if one person produces one unit of work in a unit of time, the work produced by
Ppeople in parallel in one unit of time will be:
W = (P-1) 0.5x
– ((2/(P-2) Log 2 (2/(P-2)) / 0.53
The first term,
( P-1) 0.5, represents the effect of theLaw of Diminishing Returnsfrom equation (2a) an that is multiplied by the second term,
– ((2/(P-2) Log 2 (2/(P-2)) / 0.53
, which represents the effect of theOptimal Span Hypothesis.(See the following section for the derivation of the second term in this equation.)
Application of the Optimal Span Hypothesis to the Effectiveness of Hierarchical Organizations
Hierarchy Theory[Pattee, 1973], hierarchical containment and control structures are dominant in nature and human affairs because they are more effective than non-hierarchical structures. A control hierarchy, such as the typical management organization of a project, consists of one or more layers of managers who each control a number of workers. This type of hierarchy is typically drawn as an inverted tree graph, with the top-level manager at the toprootnode.Edgesare drawn from that node down to subordinate nodes representing the lower-level managers and their departments, and so on, down to theleafnodes representing the workers who have a direct role in producing the product or service. The number of departments reporting to a higher-level manager or the number of workers reporting to a first line manager is called that manager’sSpan of Control.
Glickstein’sOptimal Span Hypothesis depends upon a concept in
Information Theorycalled theintricacyof a graph. The idea is that, given a set of resources represented as nodes and edges, there are many different ways to interconnect them. Each of these interconnection patterns may have a different amount ofintricacy, which is related to information content and is measured in bits (binary digits). The more bits the moreintricacy, and, in general,intricacyis good. All else being equal, structures with greaterintricacydo more work than structures with lessintricacy, even though both may consume the same amount of resources.
The intuitively pleasing thing about
intricacyis that it may be maximized by amoderateamount of interconnection between nodes, neither too dense nor too sparse. Structures whereallnodes are connected toallother nodes have zerointricacy,as do structures wherenoneof the nodes are connected.
For example, three alternative management hierarchy structures are shown in the figure below.
Each of the above hierarchies utilizes the same number of People (sum of the number of Managers and Workers), but (a) has a”Broad” management span of control (MSOC) of 48, (b) a “Tall” MSOC of 3.3, and (c)a “Moderate” MSOC of 6.5. Intuitively, anyone familiar with management will conclude that (c) makes much more effective use of the resources available (49 People) and that (a) has too few Managers and (b) too many.
The Optimal Span Hypothesis is merely a mathematical way to quantify this intuitive knowledge!
Quantification of Brooks “Mythical Man-Month”
In the spirit of Brooks’ paper, let usassume the “Mythical Man-Month” (MMM) is a measure of the amount of work a
superprogrammer we’ll call “Geek Zipperhead” can do in his or her best month, with absolutely no management help or interference of any kind. Unhindered by specifications, standards, design walk-throughs, code verification and validation, and not having to attend meetings of any kind, Zipperhead cranks out thousands of lines of wonderfully high quality working code per month. It lacks nothing except documentation.
Any real software department, measured by specified, standardized, verified, validated, and tested lines of code per month, is bound to be
lessefficient than Zipperhead. Buthow much lessefficient?
Consider a single-level organization, adepartment witha total of
P = 8people, one of whom is a manager, andP-1 = 7whoexert productive effort on the product or service of the department. This department has a span,S = 7.
What is the theoretical working efficiency of this single-level organization?
(a) According to the
Law of Diminishing Returnswithf= 0.5(corresponding to the square-root, SQRT of the Span), it is:
E SQRT = 100 (P-1) 0.
5 / P
The middle term is equation (2a), with
0.5substituted forf. That value represents the amount of actual work done by the workers in a month. It is divided byP, the amount of work that would be done by an ideal (and imaginary) group of super programmers without the help or interference of a manager. It is multiplied by100to get a percentage. If we substitute8forA, E SQRT = 33.1%
Note the appalling effect of the intercommunication withinsingle typical department. According to the
Law of Diminishing Returns, the coordination and communications and management of seven workers and one Manager reduces the effectiveness down to only a bit more than 33% of the amount of work a super programmer, Geek Zipperhead, could do on his or her own. Of course, Geek would takeabout threetimes as longto do the task and, since time is money, we ordinarily cannot afford the delay. Also, decisions are generally made by managers and they would all be out of work if they let Geek do the job without any management direction. If Geek left the organization, lack of clear documentation wouldbe a problem. Therefore, despite the appalling news in this Knol (and it gets more so as you read on), hierarchical organizations are definitely the way to go.
But wait, we are not done! It gets worse when we consider the additional hit imposed by the
Optimal Span Hypothesis.
(b) According to the Optimal Span Hypothesis, considered alone:
E OSH = -100((P-1)/P) (2/(P-1-1)) Log 2 (2/(P-1-1)) / 0.53
The middle term is equation (A9) [see Appendix], with
P-1substituted for the span. It is divided by 0.53, the number of bits/node that would result from an organization with an Optimal Span. It is multiplied by(P-1)/Pto account for the assumption that one of the people, themanager, does no direct productive work on the end product of the department. It is multiplied by100to get a percentage. If we substitute8forP, E OSH = 87.2%
This is for a department with a management span of control of 7 which is pretty close to optimum. Try running the above equation with fewer workers or more workersin the department and their effectiveness goes downhill. For example, for
P = 5, E OSH = 59.9%. ForP = 12, E OSH = 80.3%. ForP = 22, E OSH = 59.8%.
(c) Combining these two factors:
E C= E SQRT E OSH (P/(P-1))/100 (%) (6)
E SQRTand E OSHwe have to multiply byP/(P-1)because the non-productive manager has been accounted for separately in each and we only need to account for it once. We divide by100because both are percentages. For the department under consideration (P=8), the net E C= 33 %.ForP=5, the net E C=16.4 %.ForP=12, the net E C=24.2 %.ForP=22, the net E C =13 %.
Maximum theoretical efficiency
Note that the maximum
E Cis 35.2% and it occurs for the case of six people on the job. Thus, if we organize our project with five software engineers and a manager, we will be about 1/3 as efficient as our super programmer, Geek Zipperhead,which is the best we can hope to be. In this case,1 MMM ≈ 3 APM(Actual Person Months).
Schedule and cost issues
Well then, how long will it take to complete the project?
If it is a 100 MMM project, Geek Zipperhead, if he or she could keep up the pace that long, could theoretically do it in 100 calendar months, or about 8.3 years. That is a very long time for any project! Our eight-person department could do it in about four years, which is probably within reason. But, what if we are willing to put up with a bit more inefficiency, what is the best we can do in terms of schedule?
It turns out the fastest we could do it would be about 34 months, using a department with 18 agents. Any more agents on the job will lengthen the schedule, not shorten it!
Brooks was correct and now we know the theoretical number where Brooks Law takes effect. For a single-level organization (one department), any more than about 18 workers will actually lengthen rather than shorten the schedule!
What will the project cost? The figure below shows the relationship between duration and cost and highlights the
minimum costandminimum durationpoints.Minimum cost(for a non-Geek Zipperhead solution) is about 24 Person-Years, and that applies to a six-agent department working for 4 years.Minimum durationis 2 years and 8 months and applies to a fifteen-person gang that will cost us a whopping 48 Person-Years. The“best” plan, which is most cost-effective in terms of both cost and duration, is somewhare between these extremes. For example, a nine-person department will complete the project in 3 years and cost 27 Person-Years.
|The table below summarizes our choices. Our most practical choices are highlighted and involve completion in three to four years for a cost of about 24 to 27 agent-years.|
|Agents on Job||Efficiency (%)||Duration (Years)||Cost (Agent-Years)|
|1 (must be Zipperhead)||100||8.3||8.3|
|6 (Minimum Cost)||35.2||4||23.7|
|9 (“Best” Plan)||30.6||3||27.2|
|15 ( Minimum Duration)||19.6||2.8||42.6|