AdminLeave a comment

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

“The management and technical lessons learned from the OS/360 experience have recently been publicized in a book titled “The Mythical Man-Month: Essays on Software Engineering” by Dr. Fred Brooks, the manager of the OS/360 effort (Addison-Wesley, Reading, MA, 1975). As the title suggests, the assumed interchangeability of men and months for large software projects is severely challenged, as summarized by Brooks’ Law:
“Adding manpower to a late software project makes it later.”
The lack of  interchangeability between men and months was recognized by Dr. Brooks as being made up of two factors. First, some tasks are inherently sequential in nature, and are paced by the rate at which a single individual can do them ( more men will not decrease the time). Second, software efforts are exercises in complex relationships and require  a great amount of communication between and training of the workers involved. How then can a manager estimate or control the cost and time to deliver a software product? On what basis should management decisions be made?”

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
sinks.

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.”

Optimism

“More software projects have gone awry for lack of calendar time
than for all other causes combined. Why is this cause of disaster
so common?

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
interchangeable.

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.”

https://archive.org/details/mythicalmanmonth00fred

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
program.”

Recycling, preserving words of wisdom is just as important, if not more so, than recycling stuff.

 

 

 

Similar Posts

Leave a Reply