Why programming is fiendishly difficult and what we can do about it
summary
A codebase analysis of a 2.5 million‑line project shows 4,500 listed bugs, an effective development velocity of ~2% and a projected 300 years to clear defects if feature work stops; every bug fix spawns 1.2–3 new bugs. Root causes cluster: null pointers ~2%, sloppy error handling ~4%, exceptions ~6%, string typing ~14%, and most damage comes from debugging/repairs. Proven remedies: self-stabilizing code, fail‑safe null objects, and protect the happy path — experiments report up to 10× velocity when technical debt is eliminated at source.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 1:03Advice for newcomers
- 2:10Software unreliability
- 3:57Consultant’s codebase observations
- 7:10Bugs are systematic
- 9:17Top causes of bugs
- 12:08Bug-free code possible?
- 14:15Toyota’s production lessons
- 17:05Programming fragility
- 19:52Engineering stable systems
- 21:16Self-stabilizing systems
- 22:40Fail-safe systems
- 25:55Fail-safe code principles
- 27:19Null pointer problem
- 30:54Happy path protection
- 33:50Summary
related talks
47mBreak free from maintenance hell with Clean Code
41mWhat is stopping us? A legacy code question
32mKeeping your code strong
25mBest Practices for Writing Clean and Maintainable Codes
30mPrioritizing Technical Debt as if Time and Money Matters
46mYour Code Base as a Crime Scene
53mTechnical Enshittification: Why Everything is Horrible and How to Fix It
30mDoes Your Code Hurt?