1. Chapter Eighteen Proposition of the Mythical Man Month: True or False?

2. 1. The Tar Pit The programming system takes nine times as much effort. This is because imposed factors of three: designing, integrating, and testing components. In which cost components are independent of each other.

3. 2. The Mythical Man-Month Basically good cooking takes time sometimes things cant be hurried without spoiling the result. 1/3 schedule for design, 1/6 for coding, 1/4 component testing, and 1/4 for system testing

4. 3. The Surgical Team Different parts of a system engineering team Good professional programmers are 10x as productive than a poor one.

5. 4. Aristocracy, Democracy, and System Design Conceptual integrity when it comes to design is a must. There must be one person controlling the concepts and a group of people agreeing with him

6. 5. The Second- System Effect Second Systems are usually overdesigned. But early and continuous communication from the architect to the designer can help implementation and a clear vision

7. 6. Passing the Word Documentation of the design is a must There must be a formal definition of the design and than a more comprehensible one. This must be done by one or two people and that is it for consistency

8. 7. Why Did the Tower of Babel Fail? Communication, Communication, Communication!!! Project Workbook that is organized

9. 8. Calling the Shot One cannot accurately estimate the total effort or schedule of a programming project by simply estimating the coding time and multiplying by factors for the other parts of the task

10. 9. Ten Pounds in a Five-Pound Sack Unnecessary memory space cost lots of money. Avoid this Be strategic about the your memory space because it cost money

11. 10. The Documentary Hypothesis A small number of documents become the critical pivots around which every project’s management revolves.

12. 11. Plan to Throw One Away The deliverance of the first system will be a throw away. Can avoid this by sending out a beta version in which people can use and give feedback

13. 12. Sharp Tool A good tool is a machine that will have a good debugging system for your design

14. 13. The whole and the part The detailed architectural effort implied in Ch 4,5, and 6 make a product easier to use but it makes it easier to build and reduces the number of system bugs that have to be found.

15. 14. Hatching a Catastrophe Need to have a schedule and make milestones for yourself and the team

16. 15. The other Face A documentation for the user which is detailed but to detail so they can look up how to use the software product they have.