Supplementary Topic 7

"The Mythical Man-Month" Twentieth Anniversary Edition

• The Mythical Man-Month 1975 (chapters 1-15 of 1995 book)
  1. The Tar Pit Building a commercial product requires 9 times the time to build the component parts for private use.
  2. The Mythical Man-Month The Man-Month is a fallacious and dangerous myth, for it implies that men and months are interchangeable. More projects have gone awry for lack of calendar time than for all other causes combined.
  3. The Surgical Team Good programmers can be 10 times as productive as poor ones, given the same training and experience. A small sharp team is best.
  4. Aristocracy, Democracy, and System Design Conceptual integrity is the most important consideration in system design. One person should be in control (aristocracy).
  5. The Second-System Effect Early and continuous communcation can give the architect good cost readings and the builder confidence in the design, without blurring the clear division of responsibilities. The second is the most dangerous system a person ever designs; the general tendency is to over-design it (examples: OS/360, Windows NT).
  6. Passing the Word The design must be communicated somehow. One needs both a formal definition of a design, for precision, and a prose definition for comprehensibility.
  7. Why Did the Tower of Babel Fail? Lack of communication. Parnas argues for information hiding, and ultimately Brooks agrees.
  8. Calling the Shot Total effort cannot be predicted (as we did in PSP). Effort, or time, is not proportional to program size.
  9. Ten Pounds in a Five-Pound Sack Memory required for a program is a significant cost. Program growth must be controlled, despite the decreasing cost of memory. Data representation is the essence of programming.
  10. The Documentary Hypothesis Critical documents are: objectives, user manual, internals documentation, schedule, budget, organization chart, and floorspace allocation.
  11. Plan to Throw One Away For most large projects, the first system built is barely usable: too slow, too big, too hard to use, or all three. You will need to discard it and redesign. Both the actual need and the user's perception of that need will change as software is tested and used. Plan the Organization for Change. People will move between technical and managerial roles. "Surgical team" - all members are peers, managers and engineers. Expect maintenance to be 40% of total system cost. All fixes tend to destroy structure, and increase the disorder of a system (kludges, hacks).
  12. Sharp Tools Time should be allocated for development and support of common tools, and personalized tools. Software developed for new hardware can be developed before the hardware is ready, by using a simulator. The only reasonable candidate for system programming today is PL/1.
  13. The Whole and the Parts Many, many failures concern exactly those aspects that were never quite specified. Top-down design is critical. Structured programming is helpful in preventing bugs. One should begin system testing only after the peices seem to work. One must control and document changes and versions. Add one component at a time during system testing.
  14. Hatching a Catastrophe How does a project get to be a year late? ... One day at a time. The first step in controlling a big project on a tight schedule is to have a schedule. Milestones must be concrete, specific, measurable events defined with knife-edge sharpness. There is no substitute for critical-pah schedule to enable one to tell which slips matter how much.
  15. The Other Face The documentation is just as important as the software. Even for the most private of programs, prose documentation is necessary, for memory will fail the user-author. Laziness and schedule pressure must be overcome to produce documentation. Most documentation provides insufficient overview. Write user documentation before designing the software. Coding standards can help make a program more readable.
  
  The tar pit of software engineering will continue to be sticky for a long time to come.
  
  
• "No Silver Bullet - Essence and Accidents of Software Engineering" (chapter 16)
  • Article which appeared in 1986
  • There will be no order-of-magnitude improvement in software development in the next 10 years. (As there has been with hardware)
  • Complexity: "Software entities are more complex for their size than any other human construct." o
  • There is no good visual model for software. "The flow chart is a very poor abstraction of software structure".
  • OOP, AI, Automatic Programming, Visual Programming, Program Verification, CASE tools... None of them will improve the state of software significantly.
  • Most promising area: Off-The-Shelf (COTS, GOTS, ...)
  • "The hardest single part of building a software systems is deciding what to build". Exactly what are the requirements? Are the complete and consistent? Prototyping and incremental development are important.
  • Good software can be produced only by talented designers. Teams untalented designers cannot replace a talented designer. (see figure sup07.xls)
• "No Silver Bullet Refired" (chapter 17)
  • Commentary on original NSB article
  • Responses to criticism of NSB article
    Too pessimistic
    • Why not look at a 40 year period instead of 10?
    • Suppose NSB had been written in '52 instead of '86? Hasn't there been significant improvement?
    • Why has O-O technology grown so slowly?
    • Many critics think reuse will be the silver bullet.
  • Final position - unchanged. No silver bullet.
• Propositions from Mythical Man-Month - True or False? (chapter 18)
• Mythical Man-Month 20 Years Later (chapter 19)