Software Management Lessons from the 1960s
summary
System 360 experience and Brooks' Mytical Man Month claims stay concrete: Brooks' law: adding people to a late project makes it later because communication channels explode, Amdahl limits parallelism and even 95% parallelisable work hits a cap, and studies show 25 programmers on ~30,000 instructions produce near tenfold productivity swings. Estimates undercount QA and productization — prototypes ×3, product ×9 — and initial skeletons can consume ~40% of schedule. Reuse wins: typical codebases rely on 80–90% open source; expect to plan to throw one away.
AI-written summary · about
chapters (19)
- 0:00Start
- 0:52Ibm System / 360 Model 20
- 4:38The Mythical Man-Month
- 6:33Why Is Communication Hard
- 7:20Tasks Are Not in Fact Parallelizable
- 13:38Why Are Your Estimates Always Wrong
- 15:07Automated Testing
- 15:30How Fast Can You Code
- 19:16Planning and Documentation
- 21:20Top-Down Design
- 21:52Divide and Conquer
- 23:06Building an End-to-End Skeleton
- 27:43Hard Part of Building Software
- 29:36The Most Radical Solution for Constructing Software
- 31:38Grow Great Designers
- 32:26Software Architecture
- 34:28Conceptual Integrity
- 38:10The Users Agent
- 42:07How Big Is Big
related talks
55mSoftware Management Lessons from the 1960s
55mSoftware Management Lessons from the 1960s
01h 01mLessons from a lifetime of doing, teaching, managing, and leading technical development
33mNo Time to Do It All! Approaching Overload on DevOps Teams
59mHow Did We End Up Here?
39mThe systems thinking view on developer productivity and experience
39mImplementing Programmer Anarchy
50mMob Programming, A Whole Team Approach