Learn to appreciate legacy
summary
Code that runs matters more than rewrite fantasies: a PHP shop upgrade forces 50 hours to fix tests deploy and consolidate repos when five hours were expected, showing technical debt as real cost. Rewrites usually fail at first user contact, culture repeats past mistakes, and maintenance dominates lifecycle — estimate 20% maintenance time and follow the practical "fix at least one thing" rule to reduce risk, simplify deployments, remove dead code, and keep systems operable.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 1:12Why legacy code
- 3:05Zed's legacy struggles
- 9:13Legacy code defined
- 11:00Technical debt impact
- 13:11Developer misconceptions
- 15:46Code ownership cost
- 17:56Working vs new code
- 19:00Fixing old code
- 20:47Myth of rewrites
- 21:53Appreciate working code
- 23:15Documentation challenges
- 24:41Effective documentation
- 25:29Bus factor risks
- 26:13Maintenance as a core part of software engineering
- 26:57Joy in maintenance
- 27:19Q&A
related talks
37mLearn to appreciate legacy (Story about Zed)
57mLiving the Best Life on a Legacy Project
41mLiving the Best Life on a Legacy Project
28mReformat, Refactor, Replace: A practical guide for dealing with legacy software
45mPHP's Kitchen Nightmares
57mRefactoring a large legacy PHP Application: a case study
46mRewriting 15-Year-Old Code
36mTwenty lessons from twenty years of PHP