Software Management Lessons from the 1960s
summary
Claims that still matter: System/360 sets the 8‑bit byte and byte‑addressable memory, Brooks’s claim adding people to a late project makes it later holds because communication grows superlinearly (Amdahl style limits). Estimation error comes from counting a prototype not the full product (Brooks: a system can take ~9× the prototype effort). Large projects show this — Drupal 8 had ~5,000 contributors, Symfony ~2,176 — so prefer top‑down skeleton then iterative growth, throw one away, and aim for 80%+ open source reuse.
AI-written summary · about
chapters (11)
- 0:00Introduction and setup
- 1:27System/360 and its legacy
- 7:07Brooks' Mythical Man-Month
- 14:26Why estimates are always wrong
- 21:20Codebase growth and productivity
- 28:02Top-down design and iterative development
- 34:11Buy vs build and open source
- 40:21Growing great designers
- 43:58Conceptual integrity in design
- 50:40Leadership and architecture roles
- 54:15Final thoughts and Q&A
related talks
44mSoftware Management Lessons from the 1960s
55mSoftware Management Lessons from the 1960s
59mHow Did We End Up Here?
01h 01mLessons from a lifetime of doing, teaching, managing, and leading technical development
50mTactics and strategies on software development: how to reach ...
28mSoftware Engineering - Development in 100 Years Time
38mMore Money More Problems
16mBetter Stories, Better Software