You are on page 1of 3

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

It says that debugging is 99% complete. otherwise the employee will be less likely to given accurate status reports in the future. 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. family situations. His studies of large-scale development of a project shows that if an activity is is revised every 2 weeks. no matter how wrong they are. Chapter 15 discusses providing information to the users of your software. Brook’s focuses on the importance of Milestones. It can also be useful to use a PERT chart/critical path schedules. Although it is important that bosses must resist the temptation of asking for results when being reported delays. He mentions that milestones should reflect a set of realistic goals. illness. which discusses which asserts . The final chapters were added for the 20th anniversary edition. 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. Software disasters and problems are not due to be big events that could have been foreseen but by little things such as down-time. which all of these can significantly add up. Chapter 16 is a 1986 paper called “No Silver Bullet”. He goes on mention that you should avoid making millstones out of milestones. 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. only 90% of the time. it does not significantly change as start time draws near. this will help highlight mistakes matter and which problems to focus more attention on in order to continue progress successfully of the project.In Chapter 14.