Summary of "The Mythical Man-Month"

Core Idea

• Adding people to late projects makes them later — communication overhead and ramp-up time outweigh productivity gains (Brooks's Law)
• Conceptual integrity beats feature count — unified design vision matters far more than raw functionality
• Software is a people problem, not a technology problem — manage complexity through organization and clear roles, not tools

The Real Scheduling Problem

• Effort and time are not interchangeable — you cannot compress schedules by adding staff
• Allocate 50% of schedule for testing/debugging, not 25% — slips happen daily through small failures, not crises
• Plan to throw the first system away — expect it to be inadequate; build incrementally instead
• Track actual vs. estimated completion separately; concrete, measurable milestones only

Team Structure That Works

• One architect owns the design, many implementers build it — clear accountability prevents fragmentation
• Use surgical team model: chief programmer + copilot + specialized support (editor, toolsmith, tester)
• Small, stable teams stay coherent; large teams fracture into incompatible pieces
• Separate architecture from implementation — enables clarity and parallel work

Execution Strategy

• Build a running skeleton first, add features incrementally — always have working code
• Write specifications before coding — forces design clarity and prevents drift across the team
• Use version control and formal change logs; treat all work as team property
• High-level languages reduce time by 5x; interactive debugging cuts it further

What Fails

• Waterfall methodology — don't design everything first, test last
• Flow charts — code structure is your diagram
• Adding more programmers to late projects — communication burden swamps gains
• Expecting tools to save you — people and organization matter 10x more

Documentation & Tracking

• Create a shared project workbook: specifications, schedule, budget, org chart, change log
• Every team member accesses the same source of truth
• Plans & Controls team tracking metrics outperforms those people writing code

Long-Term Sustainability

• Maintenance costs 40% of development; one bug fix introduces another 20–50% of the time
• Design for change from the start: modular code, information hiding, abstract data types
• Program structure decays over time; plan major redesigns every few years instead of endless patches
• Buy off-the-shelf packages over building — most productive modern strategy

Action Plan

1. Appoint a single system architect accountable for user-facing design; protect them from daily management
2. Allocate time: 1/3 design, 1/6 coding, 1/2 testing/debugging — refuse to compress testing phase
3. Start with running skeleton, add incrementally — maintain working code at every stage
4. Write specifications first, maintain shared workbook — track progress rigorously against estimates
5. Keep teams small and stable — avoid adding people late; one cohesive team beats rotating large groups