The Mythical Man Month- Chapters 10-12

The Mythical Man Month: Frederick Brooks
Summary
And now we read "Documentary Hypothesis", "Plan to Throw One Away", and "Sharp Tools".

Hypothesis talks about the idea that a core set of documents forms the core of whats important to management, and furthers my theory that this book is targeted at managers of IBM systems products. To an extent it also looks at what forms this core documentation: What are the objectives, what are the specs, what is the schedule, what is the budget, "Where", and who is involved. Where lists space allocation, and based on all the other horriblenesses of the book, I'm not sure if that refers to office space, or memory space. And it says formal docs are good for communication and decision commitment.

Throw One Away talks about the concept of making an initial pass at a system, which finds many flaws and bugs in thought, and then scrapping it and starting over. The end result is a system with fewer flaws for users to encounter, at a slightly higher development time. The author talks about planning the system and organization for change. Humorous fact: in this section the author states "the problem is programmers have too little oversight from management", and the prevailing trend today is more or less "get off my back/stop micromanaging". He then talks about other things which are decidedly less interesting.

Sharp Tools states that development requires good tooling. A testing machine with at least a million bytes of storage, and a hundred million bytes of disk space is more then adequate. Simulators are useful in new terrain (and when the actual machine is busy), program libraries, profilers, tools, etc. And High Level Languages, while not yet popular (probably due to inertia) are the wave of the future!!!


Discussion:
1. Why is this paper interesting or significant?
Throw one away is an important concept, and seems almost ahead of its time considering how often it comes off as forgotten "Gospel" today.

2. What are the faults of this work?
The wrong people are reading it. Everything they say is wonderfully valid in their time frame and in their work process, but it's just not here today. Have we thought of trying "Pragmatic Programmer" instead of "Mythical Man Month"? Plz? Also, the documentation statements are kind of... fuzzy. In the context they're coming from it's important, but in modern context (applications used by users, rather then programmers), I subscribe to the theory that documentation isn't as important.

3. What is the possible future work extending from this work?
If management sees this, I forsee my development machine being downsized.