Brook’s Law the mythical man-month by Frederick Brooks, A close look at Brook’s Law by R. L. Gordon and J. C. Lamb, Selected Computer Articles 78, Recycling wisdom and words
I scanned the book that Grace Hopper sent me, “Selected Computer Articles 78” and found another article that was not on the internet and that I have a connection to.
Selected Computer Articles 78
A close look at Brook’s Law
By R. L. Gordon and J. C. Lamb
Originally published in Datamation Magazine
Frederick P. Brooks, Jr. wrote and published “the mythical man-month” in 1975.
I attended a seminar circa 1975 that he presented and purchased his book. It was well worth the time and money.
From the book.
“ABOUT THE AUTHOR
Frederick P. Brooks, Jr., is Professor and Chairman of the Com-
puter Science Department at the University of North Carolina at
Chapel Hill. He is best known as the ”father of the IBM System/
360,” having served as project manager for its development
and later as manager of the Operating System/360 software
project during its design phase. Earlier, he was an architect of the
IBM Stretch and Harvest computers.
At Chapel Hill, Dr. Brooks has participated in the establishment
and guiding of the Triangle Universities Computation Center and
the North Carolina Educational Computing Service. He has published
Automatic Data Processing, the System/360 Edition of Automatic
Data Processing, and chapters in several other books.”
The Tar Pit
“No scene from prehistory is quite so vivid as that of the mortal
struggles of great beasts in the tar pits. In the mind’s eye one sees
dinosaurs, mammoths, and sabertoothed tigers struggling against
the grip of the tar. The fiercer the struggle, the more entangling the
tar, and no beast is so strong or so skillful but that he ultimately
Large-system programming has over the past decade been
such a tar pit, and many great and powerful beasts have thrashed
violently in it. Most have emerged with running systems—few
have met goals, schedules, and budgets. Large and small, massive
or wiry, team after team has become entangled in the tar. No one
thing seems to cause the difficulty—any particular paw can be
pulled away. But the accumulation of simultaneous and interacting
factors brings slower and slower motion. Everyone seems to
have been surprised by the stickiness of the problem, and it is hard
to discern the nature of it. But we must try to understand it if we
are to solve it.
Therefore let us begin by identifying the craft of system programming
and the joys and woes inherent in it.”
“More software projects have gone awry for lack of calendar time
than for all other causes combined. Why is this cause of disaster
First, our techniques of estimating are poorly developed. More
seriously, they reflect an unvoiced assumption which is quite untrue,
i.e., that all will go well.
Second, our estimating techniques fallaciously confuse effort
with progress, hiding the assumption that men and months are
Third, because we are uncertain of our estimates, software
managers often lack the courteous stubbornness of Antoine’s chef.
Fourth, schedule progress is poorly monitored. Techniques
proven and routine in other engineering disciplines are considered
radical innovations in software engineering.
Fifth, when schedule slippage is recognized, the natural (and
traditional) response is to add manpower. Like dousing a fire with
gasoline, this makes matters worse, much worse. More fire requires
more gasoline, and thus begins a regenerative cycle which
ends in disaster.”
I marked the following passage many years ago.
“First, one must perform perfectly. The computer resembles the
magic of legend in this respect, too. If one character, one pause, of
the incantation is not strictly in proper form, the magic doesn’t
work. Human beings are not accustomed to being perfect, and few
areas of human activity demand it. Adjusting to the requirement
for perfection is, 1 think, the most difficult part of learning to
Recycling, preserving words of wisdom is just as important, if not more so, than recycling stuff.