By Justin hendrix

Chapter 1: The Tar Pit Chapter 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- Month Software 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 Team This 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 Effect The 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 Word This 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 Sack Aside 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 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. Two Steps Forward and One Step Back—Program Maintenance.

Chapter 12: Sharp Tools The 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 Parts The 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 Face For 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.