In the Mythical Man Month we start off with chapter 11.

This discusses the concept that you should build the first system just for you to throw it away. The basic idea behind this is simple. In most projects, the 1st system is barely usable, too slow, too big, awkward to use, or all 3. The point of doing this is that since the first design is usually imperfect and any design flaws would be more easily recognizable in a prototype. The questions for management then becomes whether or not to plan on doing it beforehand. He later goes on to say that you must plan for change from the beginning, and says that changes are inevitable not only in the program but in the development strategy and technique of that program as well. He says that programs need to have numbered versions, with its own schedule and freeze date, which indicates the date that changes after the date should into the next update version. Brooks continue advocating the concept that with programmers there is too little management. He says that management should assign peoples jobs with a broad focus in order to be technically flexible. He states that up to a few programmers should be kept on as the cavalry to help with extremely difficult situations. He says that senior level associates should be given training again and organized into surgical teams. After delivery of a program, it may be necessary to address program maintenance. This consists of changes that repair design defects and include added functions and are visible to the end-user. Maintenance of programs is said to be approximately at least 40% of the cost to develop it. There are other problems that can arise from the maintenance of a program. It is said that there is a high probability that fixing a defect in the program will just lead to another defect. One reason for this is that the person making the repair is not the person who wrote it but likely a junior programmer. In order to accomplish program maintenance without any complications it requires far more system testing per statement then one would when typically doing development. Brooks says that designs with less people and fewer interfaces will have less bugs in them. Since less

and less effort will be spent fixing original flaws and instead focus on fixing bugs introduced by version fixes, eventually fixing any defects in a program will begin to cease gain any ground, and will become pointless. In Chapter 12, Brooks discusses the use of a sharp tools. It is able using the right type of coding language and being able to identify whether to use a commercial tool or to make a custom designed one. He stresses the importance of developers sharing the tools they have at their disposal. If a person creates a great piece of code that can be generally applied to other people working with him he should share it. He comments that there needs to be good documentation on a project and if there were a choice between overdocumentation and underdocumentation, one should to over document. This would help later on when coders would look back at the code and try to repair or implement features of the program. Brooks states the importance of using a high level language which today would be considered C++ or Java. He says that by using one of these languages it will increase programming productivity and will help in debugging a program. He says that debugging is easier because of a better compiler that helps make finding the bug easier. Later on in chapter 13, Brooks discusses his advice on debugging programs. He goes back to his fundamental ideology that good design is a key piece in debugging. He says that there are certain rules in system debugging that one must follow. They consist of using debugged components, building plenty of scaffolding, distinguish between changes in a program (this consists of distinguishing between quick patches, and tested and detailed fixes), add one component at a time, and lastly he stresses the importance of quantization updates(building a new component needs a stable system to act as a test bed.)

In Chapter 14, Brooks focuses on the importance of Milestones. He mentions that milestones should reflect a set of realistic goals. He goes on mention that you should avoid making millstones out of milestones. He notes that from his observations when people say that coding is 90% complete it really means they are only 50% complete of total coding required. It says that debugging is 99% complete, only 90% of the time. His studies of large-scale development of a project shows that if an activity is is revised every 2 weeks, it does not significantly change as start time draws near, no matter how wrong they are. It can also be useful to use a PERT chart/critical path schedules; this will help highlight mistakes matter and which problems to focus more attention on in order to continue progress successfully of the project. When a mistake is made managers tend to try and hide them from their bosses in hoping to find a way to compensate for it somehow. Although it is important that bosses must resist the temptation of asking for results when being reported delays, otherwise the employee will be less likely to given accurate status reports in the future. Software disasters and problems are not due to be big events that could have been foreseen but by little things such as down-time, illness, family situations, which all of these can significantly add up.

Chapter 15 discusses providing information to the users of your software. This is written from a tools or OS perspective so it focuses on developers but many of the principals could be translated into modern end users.

The final chapters were added for the 20th anniversary edition. Chapter 16 is a 1986 paper called No Silver Bullet, which discusses which asserts