The Tar Pit
There is good and bad in large system design and implementation. They are what keeps us going. Creativity of design and programming and the need to be perfect every time.
The Mythical Man-Month
Estimating is hard and futile. Disasters are common. (1) estimating is poorly developed and predicated on ongoing success. (2) confuse effort with progress. (3) monitoring is poor. (4) schedule slippage is expected. "adding manpower to a late project makes it later". "The number of months of a project depends upon its sequential constraints." and the resources needed to implement them.
The implementation formula for planning, coding, testing(component, system).
The Surgical Team
A similar observation to Agile; a wide variation between good and bad programmers. In a surgical team there is specialization.
Aristocracy, Democracy, and System Design
The design must come from the mind of one or a small group. The implementation by many.
The Second-System Effect
The second system is always over designed. It's an important exercise to design and learn from but not implement.
Passing the Word
Make sure that what the designers describe is actually what is being implemented.
Why did the Tower of Babel Fall?
Failing to communicate with a large team. In modern concepts we'd be talking about internal blogs, wikis and webex. Effective communication is key in terms of timely, content, and complexity.
Calling the Shot
Through a lot of programmer productivity research and data collection... Portman, 50% of the projects take 100% more time. Aron and Harr, separately confirm that productivity is relative to complexity. OS/360, confirms Aron and Harr.
The more interesting data was from Corbato, productivity is constant in simple assignments. Productivity is increased as much as 5x in suitable high-level language.
Ten Pounds in a Five Pound Sack
"Like any cost, size itself is not bad, but unnecessary size is." In today's GEM happy Ruby and Rails programmers just install whatever they need without thinking about this. Deep dependencies have a high cost.
The Documentary Hypothesis
Project documentation may feel like an unnecessary burden but it's crucial. It's a contract from the design to the implementation. It's a contract with the stakeholders. It's a contract for the testers. Format and consistency is important.
Plan to Throw One Away
"in most projects, the first system built is barely usable" So the real question is when do you throw away the prototype. "plan for the system to change", "Plan for the organization to change".
This chapter is a little dated but the message is still the same and important. You need tools to be effective and efficient. Whether it's a Wiki, Blog, Bug tracking, continuous build, integration and deployment. You need the best, or at least good, tools.
The Whole and the Parts
Develop a roadmap, validate the roadmap then start building the road. As the system takes shape test and debug the smaller components. Assemble or integrate the components one at a time with scaffolding.
Hatching a Catastrophe
It is easy to recognize major failures that prevent a project from being completed. A building fire or a crashed system are easy. The difficulty occurs when there are minor daily events in life that cannot be made up and harder to recognize.
The Other Face
This is the deliverable. Of course there is the UX for the actual deliverable but then there is documentation, flowcharts, help. The current view
No Silver Bullet - Essence and Accident
The largest chapter so far dedicated to "no silver bullet". There have been a number of improvements from object oriented programming to code generators. None one is significant enough.
"No Silver Bullet" Refired
There has been some new research but essentially the author's position in unchanged.
Propositions of the Mythical Man-Month True or False?
If you do not want to read the book because it's too detailed or long and this doc does not provide enough info, then this chapter is for you. It's essentially a recap of the book based on today instead of 1975.
The Mythical Man-Month after 20 years
If, however, you are more interested in what might work or where Brooks admits he was wrong. Management must act deliberately and with purpose. You must have an architect for conceptual integrity. Second system has some conflict. He never considered the modern GUI desktop. It was too simple to say throw one away. It's more than that. Incremental build is good (a not so modern tool). Information hiding is good(info shared between teams). There are a number of other reversals in this chapter.