[techbooks] REVIEW: "The Mythical Man-Month", Frederick P. Brooks Jr.
- BKMYMAMO.RVW 990502
"The Mythical Man-Month", Frederick P. Brooks Jr., 1995,
%A Frederick P. Brooks Jr.
%C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%I Addison-Wesley Publishing Co.
%O U$24.69 416-447-5101 fax: 416-443-0948 bkexpress@...
%P 308 p.
%T "The Mythical Man-Month: 20th Anniversary Edition"
Brooks' work on software management is a classic, but, even with a
quarter million copies in print, it is more regarded than read. A
great many can quote Brooks' Law ("Adding manpower to a late software
project makes it later") without knowing that it was Brooks' who said
it. Which is a pity. I can fully agree with the promotional
literature that says Brooks' work is "timeless." On the "influential"
side, however, I have my doubts. If Brooks' truly had the influence
he deserved, we would have fewer late projects.
Brooks was originally writing from his experiences as project manager
for IBM's System/360, and later with OS/360. It is remarkable how
well his ideas have stood the test of time. While today we would long
for an operating system that was "bloated" to a mere 400K in size (and
I still haven't figured out the "tables" that keep being referred to),
the concepts outlined for project management are as sound today as
when first set down. And the objections raised against sound
management and documentation were as silly in 1975 as they are today.
Chapter one outlines the joy of programming, and any creative work,
and how tragically that joy can be drowned in the crush of a badly
managed project. Brooks shows very clearly how work can, and cannot,
be partitioned in chapter two. A very interesting method of
structuring a project team is given in chapter three, slightly
weakened by the ship and surgical analogies which do not fully hold up
in programming: software project teams are never faced with immediate
life and death decisions. The problem of abstracting all
"interesting" work to team leaders is examined in chapter four.
Chapter five notes a tendency to try to overcompensate for prior
missed opportunities, leading to software bloat. Team communication
is looked at two ways in chapters six and seven. Project estimation,
in chapter eight, is shown to be a poorly practiced art. Software
bloat is revisited in chapter nine, and documentation in ten. Chapter
eleven notes something we have lost sight of in our reliance on demo
software: it isn't meant to be a mere GUI shell, but a working system
that we make all the mistakes on. The need for tools, outlined in
chapter twelve, is well accepted today, but the insistence on common
tools would pull more than a few programmers up short. Modularity,
promoted in chapter thirteen, is also praised today--but not always
used. Chapter fourteen has a very solid grasp of the reasons for
project slip. Documentation, of the right sort, is reviewed in
chapter fifteen, including an attack on the venerable flowchart.
The preceding chapters are all essentially unchanged from the original
1975 edition. Chapter sixteen is Brooks' "No Silver Bullet" paper,
wherein he opined (in 1986) that programming was an inherently complex
and difficult task, and that no development in the next ten years
would provide a productivity increase on the level of an order of
magnitude. (It is interesting that Java was unleashed upon the world
at the end of that ten year projection, but, three years later, it
hasn't opened any programming floodgates either.) Brooks points out
objections to "NSB" in chapter seventeen, and answers them. The first
edition is recast in point form in chapter eighteen. Chapter nineteen
analyses what was right and enduring in the initial material, and what
was wrong in the first place.
An enduring classic that deserves to be read and re-read.
copyright Robert M. Slade, 1999 BKMYMAMO.RVW 990502
====================== (quote inserted randomly by Pegasus Mailer)
rslade@... rslade@... slade@... p1@...
The complete lack of evidence is the surest sign that
the conspiracy is working.
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
eGroups.com home: http://www.egroups.com/group/techbooks
http://www.egroups.com - Simplifying group communications