Notes for Frederick P. Brooks, Jr. The Mythical Man-Month: Essays on Software Engineering Anniversary Edition

Key concepts: conceptual integrity, message, metaprogramming, network, program, surgical team.


Related theorists: Conway, Cosgrove, Harlan Mills, Scott Rosenberg, E. F. Schumacher.


Preface to the 20th Anniversary Edition

Research shifted to virtual environments.

(viii) Since 1986, I have only taught software engineering, not done research in it at all. My research has rather been on virtual environments and their applications.


Preface to the First Edition
(x)


1
The Tar Pit

The Programming Systems Product

The Joys of the Craft

The Woes of the Craft


2
The Mythical Man-Month

Success of software projects largely impacted by lack of calendar time due to poor estimating, confusing effort with progress, poor monitoring, and finally adding manpower when slipping noticed; ironically, forty years later these comments are still appropriate for the mid size software development firm where I work.

(14) More software projects have gone awry for lack of calendar time than for all other causes combined.
(14) First, our techniques of estimating are poorly developed.
(14) Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.
(14) Third, because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine's chef [referring to quotation from menu that good cooking takes time].
(14) Fourth, schedule progress is poorly monitored.
(14) Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower.

Optimism

Expectation of tractable medium for software breeds fallacious thought mode of pervasive optimism, but faulty ideas lead to bugs.

(15) In many creative activities the medium of execution is intractable.
(15) Implementation, then, takes time and sweat both because of the physical media and because of the inadequacies of the underlying ideas.
(15) The programmer builds from pure thought-stuff: concepts and very flexible representations thereof. Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified.

The Man-Month

Unlike cost progress does not very by number of men and months, making man month deceptive unit for measuring size of a job.

(16) The second fallacious thought mode is expressed in the very unit of effort used in estimating and scheduling: the man-month. Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable.

Men and months only interchangeable when task can be partitioned with no communication needs.

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

Sequential constraints also prevent task partitioning, like bearing a child.

(17) When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging.

Communication adds burden of training and intercommunication.

(18) The added burden of communication is made up to two parts, training and intercommunication.
(18) If each part of the task must be separately coordinated with each other part, the effort increases as n(n-1)/2.

Communication quickly dominates task time when workers are added.

(19) 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.

Systems Test

Testing usually most misleading part of schedule because of optimistic expectation of less bugs.

(19-20) Because of optimism, we usually expect the number of bugs to be smaller than it turns out to be. Therefore, testing is usually the most mis-scheduled part of programming.

Brooks uses one third planning, one sixth coding, one quarter component test, one quarter system test as scheduling rule of thumb, although few of the conventionally scheduled projects he studied allowed one half for testing.

(20) In examining conventionally scheduled projects, I have found that few allowed one-half of the projected schedule for testing, but that most did indeed spend half of the actual schedule for that purpose. Many of these were on schedule until and except in system testing.

Gutless Estimating

Common practice of scheduling to match date desired by patron.

(21) Now I do not think software managers have less inherent courage and firmness than chefs, nor than other engineering managers. But false scheduling to match the patron's desired date is much more common in our discipline than elsewhere in engineering.

Regenerative Schedule Disaster

Extended example of regenerative schedule disaster from adding manpower yields famous law, demythologizing the man month.

(25) Without a doubt, the regenerative disaster [from adding workers who need training and intercommunication] will yield a poorer product, later, than would rescheduling with the original three men, unaugmented.
(25) Oversimplifying outrageously, we state Brooks's Law: Adding manpower to a late software project makes it later.
(25-26) This then is the demythologizing of the man-month. 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 define 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.


3
The Surgical Team

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

Mills's Proposal

The surgeon.

The copilot.

The administrator.

The editor.

Two secretaries.

The program clerk.

The toolsmith.

The tester.

The language lawyer.

How It Works

Scaling Up


4
Aristocracy, Democracy, and System Design

Conceptual Integrity

Achieving Conceptual Integrity

Aristocracy and Democracy
(46) If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs to apology.

Unapologetic about control of architectural specification by a small group, aristocracy, versus majority of implementors; similar arguments made in Dreaming in Code but also complicates analysis of free software open source bazaar ethic.

(46) The design of an implementation, given an architecture, requires and allows as much design creativity, as many new ideas, and as much technical brilliance as the design of the external specifications.

What Does the Implementor Do While Waiting?

Value of consistent design philosophy is conceptual integrity; integral systems take less time to build.

(49-50) Conceptual integrity does require that a system reflect a single philosophy and that the specification as seen by the user flow from a few minds. Because of the real division of labor into architecture, implementation, and realization, however, this does not imply that a system so designed will take longer to build. Experience shows the opposite, that the integral system goes together faster and takes less time to test. In effect, 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.


5
The Second-System Effect


6
Passing the Word


Formal Definitions
(64) Almost all formal definitions turn out to embody or describe an implementation of the hardware or software system whose externals they are prescribing. Syntax can be described without this, but semantics are usually defined by giving a program that carriers out the defined operation.


7
Why Did the Tower of Babel Fail?


Organization in the Large Programming Project

Network communications natural state in large organizations, including programming projects.

(79) But the communication structure is not so restricted, and the tree is a barely possible approximation to the communication structure, which is a network.

Prevalence of producers and technical directors in network organizations; rarity of thinkers, doers, and thinker-doers.

(80) The producer and the technical director may be the same man. . . . Thinkers are rare; doers are rarer; and thinker-doers are rarest.

Does use of gendered abstract noun man fail to properly consider role of women in programming, the true long hairs, or does Brooks innocently equivocate and intend to include all humans?

(80) The producer may be boss, the director his right-hand man.
(81) The job done least well by project managers is to utilize the technical genius who is not strong on management talent.


9
Ten Pounds in a Five-Pound Sack


Size Control

Holistic, user oriented attitude crucial characteristics of programming manager.

(100) All during implementation, the system architects must maintain continual vigilance to ensure continued system integrity. Beyond this policing mechanism, however, lies the matter of attitude of the implementers themselves. Fostering a total-system, user-oriented attitude may well be the most important function of the programming manager.


10
The Documentary Hypothesis


Documents for a Software Project
(110-111) What: objectives.
What: product specifications.
When: schedule
How much: budget
Where: space allocation

Social aspect of technological unconscious includes very shape of systems reflecting organizational communication structures, from primitive workshops to networks; contemplate this supposition that programming systems reflect the communication structures of the organizations creating them with respect to individual projects as an obvious passage into programming style.

(111) Who: organization chart. This becomes intertwined with the interface specification, as Conway's Law predicts: “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.”

Why Have Formal Documents?

(111) 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.
(111) Second, the documents will communicate the decisions to others.

Compare value of managerial documents to Caesear notebooks used by Antony.

(111) Finally, a manager's documents give him a data base ad checklists.
(112) If their comprehensive and critical nature is recognized in the beginning, the manager can approach them as friendly tools rather than annoying busywork.


11
Plan to Throw One Away

Pilot Plants and Scaling Up

The Only Constancy Is Change Itself
(117)
Cosgrove has perceptibly pointed out that the programmer delivers satisfaction of a suer need rather than any tangible product. And both the actual need and the user's perception of that need will change as programs are built, tested, and used.


Plan the Organization for Change

(120) The whole notion of organizing surgical-type programming teams is a radical attack on this problem. It has the effect of making a senior man feel that he does not demean himself when he builds programs, and it attempts to remove the social obstacles that deprive him of that creative joy.


12
Sharp Tools

(128) The manager of a project, then, needs to establish a philosophy and set aside resources for the building of common tools.


13
The Whole and the Parts


Component Debugging

Original of time sharing in debugging, a programming activity, sets stage for GUI and myriad other ways of human and computer interaction.

(146) Interactive debugging. In 1959 Codd and his coworkers and Strachey each reported work aimed at time-shared debugging, a way of achieving both the instant turnaround of on-machine debugging and the efficient machine use of batch debugging.


14
Hatching a Catastrophe


Under the Rug
(157) Reducing the role conflict. The boss must first distinguish between action information and status information. He must discipline himself not to act on problems his managers can solve, and never to act on problems when he is explicitly reviewing status.


15
The Other Face

Definition of program/programming invicts materiality of programming, noting category mistake to cycle around code this good description sets stage for later thought in philosophy of computing see how we are going tapoc into working code trance knowledge state cycling through systems of machine and human conspiracy, for example C and English, C++ and ancient Greek, Perl and Latin, and so on; I suggest today that in the complexity of program products as deployed solutions we miss communicating with the machine as programmers, exemplified by workplaces lacking weekly seminars on deployed solutions products.

(164) A computer program is a message from a man to a machine. The rigidly marshaled syntax and the scrupulous definitions all exist to make intention clear to the dumb engine.
(164) But a written program has another face, that which tells its story to the human user. For even the most private of programs, some such communication is necessary; memory will fail the author-user, and he will require refreshing on the details of his handiwork.
(164) For the program product, the other face to the user is fully as important as the face to the machine.


19
The
Mythical Man-Month after 20Years
Why Is There a Twentieth Anniversary Edition?

The Central Argument: Conceptual Integrity and the Architect
(255)
Conceptual integrity. A clean, elegant programming product must present to each of its users a coherent mental model of the application, of strategies for doing the application, and of the user-interface tactics to be used in specifying actions and parameters. The conceptual integrity of the product, as perceived by the user, is the most important factor in ease of use.

The power of Giving Up Power
(277) E. F.
Schumacher, in his classic, Small is Beautiful: Economics as if People Mattered, proposes a theory of organizing enterprises to maximize the creativity and joy of the workers.

Is delegated power like distributed control an important question arising from crossing Brooks with Berry and fortuitously Janz while writing code, in the midst of working code is where philosophy multipurposively crosses over into technology.

(279) It yields exactly the benefits Pius XI predicted: the center gains in real authority by delegating power, and the organization as a whole is happier and more prosperous.

Buy and Build—Shrink-Wrapped Packages As Components

Foresees but does not name the emergence of the free, open source option, whole operating systems built from these components, in a programming platform statement anticipating floss; metaprogramming is the organizational discipline appropriate to range over configuration of personal operating environments, with unreflective consumption at the other pole.

(284) Radically better software robustness and productivity are to be had only by moving up a level, and making programs by the composition of modules, or objects. An especially promising trend is the use of mass-market packages as the platforms on which richer and more customized products are built.

Where metaprogramming descends back into interface, user has option to become less intellectually challenged as to have to consider how these things constituting thought are arranged.

(285) Metaprogramming. Building Hypercard stacks, Excel templates, or MiniCad functions is sometimes called metaprogramming, the construction of a new layer that customizes function for a subset of a package's users. . . . while we have been waiting to see an effective market in C++ classes develop, a market in reusable metaprograms has grown up unremardked.



Brooks, Jr., Frederick P. The Mythical Man-Month: Essays on Software Engineering Anniversary Edition. Boston: Addison Wesley Longman, Inc., 1995. Print.