The Mythical Man-Month
The Mythical Man-Month devotes most of its essays to the
managerial aspects of software engineering, rather than the many technical
issues. The book sprang from a conviction that the quality of the people on a
project, and their organization and management, are much more important factors
in success than are the tools they use or the technical approaches they take.
- The tar pit
- The mythical man-month
- The man-month is a fallacious and dangerous myth, for it implies that men
and months are interchangeable.
- Brooks's Law: Adding manpower to a late software project makes it later.
- The surgical team
- Aristocracy, democracy, and system design
- The second-system effect
- The second is the most dangerous system a person ever designs; the general
tendency is to over-design it.
- Passing the word
- Why did the Tower of Babel fail?
- Calling the shot
- Ten pounds in a five-pound sack
- On large teams, subteams tend to suboptimize to meet their own targets rather
than think about the total effect on the user. This breakdown in orientation is a
major hazard to large projects.
- Fostering a total-system, user-oriented attitude may well be the most important
function of the programming manager.
- Lean, spare, fast programs are almost always the result of strategic
breakthrough, rather than tactical cleverness.
- Often, such a breakthrough will be a new algorithm.
- More often, the breakthrough will come from redoing the representation of the
data or tables. Representation is the essense of programming.
- The documentary hypothesis
- The hypothesis: Amid a wash of paper, a small number of documents become the
critical pivots around which every project's management revolves. These are the
manager's chief personal tools.
- Each document serves as a checklist and a database.
- Plan to throw one away
- For most projects, the first system built is barely usable: too slow, too
big, too hard to use, or all three.
- The discard and redesign may be done in one lump, or piece-by-piece, but
it will be done.
- Sharp tools
- System debugging, like astronomy, has always been done chiefly at night.
- The whole and the parts
- Hatching a catastrophe
- The other face
- The flow chart is a most thoroughly oversold piece of program documentaion;
the detailed blow-by-blow flow chart is a nuisance, obsoleted by written
- To keep documentation maintained, it is crucial that it be incorporated in
the source program, rather than kept as a separate document.
- No silver bullet - essence and accident
- Most past progress in software productivity has come from eliminating
noninherent difficulties such as awkward machine languages and slow batch
- There are not a lot more of these easy pickings.
- Radical progress is going to have to come from attacking the essential
difficulties of fashioning complex conceptual constructs.
- "No silver bullet" refired
- "The part of software building I called essence is the mental
crafting of the conceptual construct; the part I called accident
is its implementation process."
- Object-Oriented programming - will a brass bullet do? Front-loaded costs,
- What about reuse? Requires higher level vision, insight, and abstraction.
The higher the level at which one thinks, the more numerous the primitive
thought-elements one has to deal with. Vocabulary learning constitutes no
small part of the intellectual barrier to reuse.
- Propositions of The Mythical Man-Month: true or false?
- A summary of the assertions discussed in the original 15 chapters.
- The Mythical Man-Month after 20 years
- The Waterfall Model is wrong. An Incremental-Build Model is better.
Experience and ideas from each downstream part of the construction process must
leap upstream, sometimes more than one stage, and affect the upstream
- Perhaps the maturation of programming into software engineering will
parallel the evolution of chemistry into chemical engineering. Chemical
engineering was fairly immature in 1945. It was only after WWII that chemical
engineers really addressed the behavior of closed-loop interconnected