The Mythical Man-Month

The Mythical Man-Month
Fred Brooks

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 Chapters

  1. The tar pit
  2. 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.
  3. The surgical team
  4. Aristocracy, democracy, and system design
  5. The second-system effect
    • The second is the most dangerous system a person ever designs; the general tendency is to over-design it.
  6. Passing the word
  7. Why did the Tower of Babel fail?
  8. Calling the shot
  9. 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.
  10. 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.
  11. 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.
  12. Sharp tools
    • System debugging, like astronomy, has always been done chiefly at night.
  13. The whole and the parts
  14. Hatching a catastrophe
  15. 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 high-level languages.
    • To keep documentation maintained, it is crucial that it be incorporated in the source program, rather than kept as a separate document.
  16. 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 turnaround.
    • 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.
  17. "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, down-stream benefits.
    • 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.
  18. Propositions of The Mythical Man-Month: true or false?
    • A summary of the assertions discussed in the original 15 chapters.
  19. 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 activity.
    • 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 continous-flow systems.