Propositions of The Mythical Man-Month: True or False?

By Justin hendrix

Chapter 1: The Tar PitChapter one is about making a good project

that won’t get stuck in the “tar pit.” That is it must be flexible and written to last. Testing, documentation and maintenance are very important are very crucial factors for the prevention of a tar pit.

Chapter 2: The Mythical Man-MonthSoftware engineering is the strive for

excellence. Don’t go to fast or slow and make it right. This chapter is basically about everything (good estimates, Communication, Testing, ect..).

Chapter 3: The Surgical TeamThis chapter is about the

right team size, and its members. The Ideal team is 10 people: The Surgeon, The Copilot, The Administrator, The Editor, Two Secretaries, and The Program Clerk.

Chapter 5: The Second-System EffectThe Second System Effect is

when a programmer successfully finishes a project and on the second project, goes too far with the design (making it too complicated).

Vista is a good example of the second-system effect.

Chapter 6: Passing the WordThis Chapter is about

Documentation. A good SOM and comments allows for easier maintenance.

Even when a design team is large, the results must be reduced to writing by one or two, in order that the mini-decisions be consistent.

Chapter 7: Why Did the Tower of Babel Fail?

This chapter is about how good communicating is vital. Like the last chapter keep good documentation, but also keep good workbooks and have steady productive meetings.

Chapter 9: Ten Pounds in a Five-Pound SackAside from running time, the memory space

occupied by a program is a principal cost. This is especially true for operating systems, where much is resident all the time.

Size does matter.Effective code is better than large code.

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

For a computer development project, the critical documents are the objectives, manual, schedule, budget, floorspace allocation, and the estimate, forecast, and prices of the machine itself.

Chapter 11: Plan to Throw One AwayFor 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.

Two Steps Forward and One Step Back—Program Maintenance.

Chapter 12: Sharp ToolsThe manager of the project needs to establish

a philosophy and set aside resources for the building of common tools, and at the same time to recognize the need for personalized tools.

The debugging machine, or its software, needs to be instrumented, so that counts and measurements of all kinds of program parameters can be automatically made.

Chapter 13: The Whole and the PartsThe detailed, painstaking

architectural effort implied in Chapters 4, 5, and 6 not only makes a product easier to use, it makes it easier to build and reduces the number of system bugs that have to be found.

A good top-down design avoids bugs in many was.

Sometimes one has to go back, scrap a high level, and start over.

Chapter 14: Hatching a Catastrophe“How dose a project get to be a

year late?...One day at a time.”Day-by-day schedule slippage is

harder to recognize, harder to prevent, and harder to make up then calamities.

Milestones must be concrete, specific, measurable events defined with knife-edge sharpness.

Chapter 15: The Other FaceFor the program product, the other face to

the user, the documentation, is fully as important as the face to the machine.

A program should be shipped with a few test cases, some for valid input data, some for borderline input data, and some for clearly invalid input data.