Adding People Makes It Later

The Core Insight

Brooks ran the OS/360 software project with more than a thousand people at peak. From 1963 through 1966, probably 5,000 man-years went into its design, construction, and documentation. It shipped late. He left IBM in 1965, and the essays that became this book landed in 1975.

The 1995 anniversary edition reprints those essays untouched except for trivial corrections. It adds four chapters, one of them the 1986 paper No Silver Bullet. Chapter 2 opens and closes on the same count. More software projects have gone wrong for lack of calendar time than for all other causes combined.

Most managers read a slipping schedule as a staffing problem, and they add people. Brooks argues that cost varies as the product of men and months, and progress does not. Men and months trade only where the work partitions and the workers never have to talk. Bearing a child takes nine months, whatever the headcount.

The deeper claim arrives in 1986. Software carries essential difficulty, the fashioning of the conceptual construct, and accidental difficulty, its representation in a language on a machine. Every breakthrough he can name attacked the accident. His claim is that no single development in technology or management promises even a tenfold improvement within a decade.

The Framework

Most underestimates begin by pricing the wrong object. A program that runs on its author's machine is the cheapest thing in the field. A programming product is one anybody can run, test, repair, and extend, with generalized inputs, a bank of test cases, and thorough documentation. It costs at least three times as much. A programming system component belongs to a coordinated collection with defined interfaces and a budget of memory, input-output, and time. Testing it in every expected combination costs another factor of three. Both together give the programming systems product at nine times the price, and Brooks calls it the only useful object.

The schedule then splits in a ratio he gives exactly.

• Planning takes one third, which is more than usual and barely enough for a solid specification.
• Coding takes one sixth, and it is the part most people estimate well.
• Component test and early system test take one quarter.
• System test, with all components in hand, takes the last quarter.

Half the schedule is debugging. Few projects allowed that much, and most spent it anyway. A slip found in late system test is the worst kind, because the news arrives near delivery, at the maximum cost per day.

No Silver Bullet supplies the arithmetic that closes the argument. Unless the accident is more than nine tenths of all effort, driving every accidental task to zero cannot produce a tenfold gain.

Key Ideas

Communication Cost Is Why a Late Project Gets Later

Added people bring two costs. Training cannot be partitioned, so that part of the effort grows in a straight line with the number of workers. Intercommunication grows as n(n-1)/2. Three workers need three times the pairwise communication of two, and four need six times. Multi-way conferences make it worse, and the communication effort soon passes the time that partitioning saved.

His worked example is a twelve man-month job: three people, four months, four milestones. The first milestone slips to month two. If only that part was misestimated, nine man-months remain in two months, and the job needs four and a half people. If the whole estimate was low, eighteen remain, and it needs nine. Training the two new people costs an experienced man a month, and the three-way split becomes a five-way split. Hitting the original date takes four added people rather than two.

In 1995 he lets two studies qualify the law. Boehm studied some 63 projects and found a cost-optimum schedule of 2.5 times the cube root of the man-months. Hardly any project ships in less than three quarters of that time, whatever the headcount. Abdel-Hamid and Madnick find that adding people always costs more, and does not always finish later. Early additions are safer. He keeps the bald statement as the best zeroth-order approximation to the truth.

The honest alternatives are a reschedule and a formal cut. Fagg's rule for rescheduling is to take no small slips. The task gets trimmed either way, and the silent trim arrives as hasty design and skipped tests.

Conceptual Integrity Outranks Good Ideas

Brooks ranks conceptual integrity as the most important consideration in system design. A system that omits anomalous features to hold one set of design ideas beats a system carrying many good, uncoordinated ones. The ratio of function to conceptual complexity is his test of a design. Integrity of that kind comes from one mind, or from a very small number of agreeing minds.

So he splits architecture from implementation. Architecture is the complete and detailed specification of the user interface, and the architect is the user's agent. Blaauw put it plainly: architecture tells what happens, implementation tells how it is made to happen. A clock is a face, hands, and a winding knob. One System/360 architecture ran on some nine implementations.

He names the objection himself and takes it: an aristocracy that needs no apology. Implementation carries as much design creativity, and form is liberating.

He also prices his own worst call. The architecture manager had ten good people and needed ten months, three more than the schedule allowed. The control program manager had 150 people and promised the date. Brooks took the 150. The work came in three months late anyway, at lower quality, and the missing conceptual integrity added a year to debugging.

The Second System Is the Dangerous One

A first design comes out spare and clean, because the architect knows he does not know what he is doing. The frills go in a drawer for next time. The second system empties the drawer, and Brooks calls it the most dangerous system a man ever designs. By the third, the earlier experiences confirm each other.

The 709 and 7090 followed the 704, and only about half of the result was regularly used. OS/360 spends 26 bytes of a permanently resident routine on December 31 in leap years.

He offers two defenses. Price each function before it is built. Capability x is worth no more than m bytes of memory and n microseconds per invocation. And insist that the senior architect has at least two systems behind him.

Projects Slip One Day at a Time

A project gets to be a year late one day at a time. The disaster comes from termites, not tornadoes. A calamity gets the team to rise. Day-by-day slippage is harder to see, harder to prevent, and harder to make up.

So milestones must be concrete, specific, measurable events, defined with knife-edge sharpness. Coding sits at 90 percent finished for half the coding time. Debugging sits at 99 percent complete for most of its duration. Planning complete is an event anyone can proclaim at will.

Real milestones are 100 percent events. His examples: a specification signed by both sides, source coding complete and in the disk library, a debugged version passing every test case. A person rarely lies about a milestone sharp enough that he cannot deceive himself. Vyssotsky's discipline keeps two sets of dates, scheduled and estimated, and the project manager keeps his fingers off the estimates.

Two contractor studies found an asymmetry. Overestimates come down steadily once an activity runs, and underestimates hold until about three weeks before the scheduled completion.

Brooks Retracted His Most Quoted Line

Plan to throw one away, you will anyhow. The 1975 case is a pilot plant. A desalting process gets tested at 10,000 gallons a day before a community system runs 2,000,000. The first system built is barely usable, so the only question is whether the throwaway goes to customers.

Twenty years later he calls that advice wrong for being too simplistic. Its hidden assumption is the waterfall model, which allows one pass and puts all the mistakes in the realization. He names the chapter 2 scheduling rule as carrying the same taint. The waterfall defers system test, and user testing with it, until construction finishes.

His replacement is incremental build, taken from Mills. Build the main loop with null stubs, compile it, and test it going round and round doing nothing correctly. Add the input and output modules, then one function at a time. A working system exists at every moment, users test early, and building to budget protects the schedule at the cost of function. He reports the effect of that first running picture on team morale as electrifying.

The same chapter carries a second retraction. Parnas was right about information hiding, and Brooks now takes encapsulation as the only way to raise the level of software design.

No Tool Buys an Order of Magnitude

Four difficulties make the essence hard. Complexity, because no two parts of a software entity are alike above the statement level, and scale adds different elements that interact nonlinearly. Conformity, because the interfaces were designed by different people rather than by God, so the complexity is arbitrary. Changeability, because all successful software gets changed and outlives the machine it was written for. Invisibility, because software has no shape in space, and diagramming it yields several superimposed directed graphs that are usually not even planar.

Past gains attacked the accident. High-level languages bought at least a factor of five in productivity. Time-sharing bought what remained by cutting delay under the threshold of noticeability, about 100 milliseconds. He then walks the 1986 candidates and rejects each: Ada, object-oriented programming, artificial intelligence, expert systems, automatic programming, and program verification.

He proposes four attacks on the essence: buying instead of building, refining requirements with prototypes, growing systems, and paying great designers. The hardest single part of building a software system is deciding precisely what to build. In 1995 he puts the accidental part of the work at about half of the total or less. Nobody, he notes, has claimed publicly that it runs to nine tenths.

Practical Applications

Price the object before you price the schedule. Decide whether you are building a program, a product, a system component, or all three, then multiply by three per step. Most overruns start by quoting the garage version.

Lay your plan against his ratio. One third planning, one sixth coding, one quarter component and early system test, one quarter full system test. A plan that gives testing less than half finds its slip too late to absorb it.

Name one architect, and keep that job separate from the manager. Brooks came to insist on the split for teams as small as four. Where the system is too big for one mind, partition where the interfaces are smallest and give each subsystem its own architect.

Rewrite every milestone as a 100 percent event with an artifact or a signature attached. Anything fuzzier grinds down morale and reports nothing.

Grow the system instead of building it. Ship a skeleton that runs and does nothing correctly, then add function while it keeps running. Rebuild every night, and stop the whole process when the build breaks until the fault is found and fixed.

Who This Is For

Founders and engineering managers running work past the point where everyone hears everything get the most from it. The arithmetic holds anywhere the work is conceptual and the parts must fit. A compiler qualifies, and so does a product with three teams touching it.

Skip it if you are two people in one room shipping one program. Brooks's own line for that size is a team of two with one leader. The rest of the book treats a problem you do not have yet.

The vintage shows. The examples are IBM mainframes of the 1960s, counted in bytes of core and machine-room shifts. The productivity tables are assembler statements per man-year. Brooks retracts the 1.5 effort exponent in his propositions chapter, where Boehm's data put it between 1.05 and 1.2. The anniversary chapters have him overturning his own headline advice twice, on throwaway systems and on information hiding. Modern practice answered several of the open problems. High-level languages and interactive programming are universal now. Virtual memory and cheap memory ended the size economics. The nightly rebuild makes the small frequent change quanta he called too risky work.

The Decision

Take the project that is late right now and run the count. Write down the number of people on it, then compute n(n-1)/2 for the communication paths. Compare it with the number from the day the schedule was set.

Then test whether the work that remains partitions without those paths. If it does, more people can help. If it does not, two honest moves remain. Reschedule with no small slip, or cut function formally while you still pick which function.

Adding people is the third move, and it is the one that makes the arithmetic worse.