Frederick P. Brooks Quotes, Part 1

A couple of years ago I started The Mythical Man Month by Frederick P. Brooks, and I am ashamed to say, got sidetracked about half-way through; however I have recently resumed my reading. Fortunately the chapters stand alone quite well, so the continuity loss is minor. I intend to share, over the course of a few posts, quotes that I find important in the text. Though written across the 70s - 90s, Mythical holds a tremendous amount of wisdom developed within a particular historical context. That wisdom is still relevant today, thought the specific technical challenges that gave rise to that wisdom have morphed – almost beyond recognition – over time.


Briefly, I believe that large programming projects suffer management problems different in kind from small ones, due to division of labor. I believe the critical need to be the preservation of the conceptual integrity of the product itself.

Chapter 1: The Tar Pit

The obsolescence of an implementation must be measured against other existing implementations, not against unrealized concepts.

Chapter 2: The Mythical Man-Month

…our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.

Cost does indeed vary as the product of the number of men and the number of months. Progress does not.

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them.

When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. [emphasis mine]

Since software construction is inherently a systems effort—an exercise in complex interrelationships—communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. Adding more men then lengthens, not shortens, the schedule.

…the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion.

…false scheduling to match the patron’s desired date is much more common in our discipline than elsewhere in engineering.

Adding manpower to a late software project makes it later. [emphasis mine]

The number of months of a project depends upon its sequential constraints. The maximum number of men depends upon the number of independent subtasks. From these two quantities one can derive schedules using fewer men and more months. (The only risk is product obsolescence.) One cannot, however, get workable schedules using more men and fewer months.

Chapter 3: The Surgical Team

…the sheer number of minds to be coordinated affects the cost of the effort, for a major part of the cost is communication and correcting the ill effects of miscommunication (system debugging). This, too, suggests that one wants the system to be built by as few minds as possible.

This then is the problem with the small, sharp team concept: it is too slow for really big systems.

For efficiency and conceptual integrity, one prefers a few good minds doing design and construction. Yet for large systems one wants a way to bring considerable manpower to bear, so that the product can make a timely appearance.

In the surgical team, there are no differences of interest, and differences of judgment are settled by the surgeon unilaterally. These two differences—lack of division of the problem and the superior-subordinate relationship—make it possible for the surgical team to act uno animo.

Chapter 4: Aristocracy, Democracy, and System Design

I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas. [emphasis mine]

For a given level of function, however, that system is best in which one can specify things with the most simplicity and straightforwardness.

Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds. [emphasis mine]

…the lack of conceptual integrity made the system far more costly to build and change, and I would estimate that it added a year to debugging time.

The opportunity to be creative and inventive in implementation is not significantly diminished by working within a given external specification, and the order of creativity may even be enhanced by that discipline. The total product will surely be.

…refrain from hiring implementers until the specifications are complete. This is what is done when a building is constructed.

…the integral system goes together faster and takes less time to test… a widespread horizontal division of labor has been sharply reduced by a vertical division of labor, and the result is radically simplified communications and improved conceptual integrity.

Chapter 5: The Second-System Effect

How does the architect avoid the second-system effect [i.e., the tendency to over-compensate for things that were sidelined in the first system, or prototype, by introducing massive bloat in the second iteration of a piece of software]? Well, obviously he can’t skip his second system. But he can be conscious of the peculiar hazards of that system, and exert extra self-discipline to avoid functional ornamentation and to avoid extrapolation of functions that are obviated by changes in assumptions and purposes.

Chapter 6: Passing the Word

The architect must always be prepared to show an implementation for any feature he describes, but he must not attempt to dictate the implementation.

Chapter 7: Why did the Tower of Babel Fail?

The purpose of organization is to reduce the amount of communication and coordination necessary… [emphasis mine]

The job done least well by project managers is to utilize the technical genius who is not strong on management talent.

Chapter 8: Calling the Shot

…the estimating error [of delivery time] could be entirely accounted for by the fact that his teams were only realizing 50 percent of the working week as actual programming and debugging time. Machine downtime, higher-priority short unrelated jobs, meetings, paperwork, company business, sickness, personal time, etc. accounted for the rest. In short, the estimates made an unrealistic assumption about the number of technical work hours per man-year. [emphasis mine]

Chapter 10: The Documentary Hypothesis

Conway’s Law predicts: “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.” Conway goes on to point out that the organization chart will initially reflect the first system design, which is almost surely not the right one. If the system design is to be free to change, the organization must be prepared to change. [emphasis mine]

…writing the decisions down is essential. Only when one writes do the gaps appear and the inconsistencies protrude. The act of writing turns out to require hundreds of mini-decisions, and it is the existence of these that distinguishes clear, exact policies from fuzzy ones.

Chapter 11: Plan to Throw One Away

…the programmer delivers satisfaction of a user need rather than any tangible product… [emphasis mine]

Program maintenance involves no cleaning, lubrication, or repair of deterioration. It consists chiefly of changes that repair design defects. [emphasis mine]

[The total cost of maintaining a widely used program] is strongly affected by the number of users. More users find more bugs. [emphasis mine]

All repairs tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws introduced by earlier fixes.

Chapter 12: Sharp Tools

I have postulated one toolmaker per team. This man masters all the common tools and is able to instruct his client-boss in their use. He also builds the specialized tools his boss needs.

Chapter 13: The Whole and the Parts

The most pernicious and subtle bugs are system bugs arising from mismatched assumptions made by the authors of various components.

[Niklaus Wirth’s] procedure is to identify design as a sequence of refinement steps. One sketches a rough task definition and a rough solution method that achieves the principal result. Then one examines the definition more closely to see how the result differs from what is wanted, and one takes the large steps of the solution and breaks them down into smaller steps. Each refinement in the definition of the task becomes refinement in the algorithm for solution… from this process one identifies modules of solution or of data whose further refinement can proceed independently of other work… [use] as high-level a notation as is possible at each step, exposing the concepts nad concealing the details until further refinement becomes necessary.1

Many poor systems come from an attempt to salvage a bad basic design and patch it with all kinds of cosmetic relief.

To be continued…

  1. I call this process “rought draft programming” when applied to implementation. When applied to planning, this is essentially the he heart of the agile feedback loop.