Changing attitudes toward legacy code
summary
Panelists report concrete playbooks: prioritize add tests first and map interdependencies before any rewrite, keep Objective‑C/Swift interop or Chrome DevTools history in place rather than ripping everything out, and treat big rewrites as risky — avoid big‑bang rewrites by migrating incrementally. Teams log decisions with architecture decision records, pair on unknown areas, use docs for complex transformation rules, and quantify the choice by measure time lost vs rebuild time so investment and disruption have clear numbers.
AI-written summary · about
chapters (17)
- 0:00Intro
- 2:40Legacy software
- 4:10Truman
- 4:55Jack
- 8:37Hate stories
- 11:06Google
- 12:52How do you face it
- 16:37Two strategies
- 19:10Top tips
- 23:15Legacy stories
- 28:54Learning from legacy code
- 30:42Mindset
- 32:42Audience questions
- 35:17Making it easier for your future self
- 37:11Architecture decision records
- 38:38What are your heuristics
- 40:15When to rewrite a legacy code
related talks
32mLegacy Code: Big Rewrite or Progressive Rejuvenation?
01mThe Path Through Legacy: Delicate Balance Between Tolerance and Phobia
11mThe monster under the bed - working with legacy code
41mRefactoring your legacy applications the right way
37mGrowing a Joyful Codebase from Legacy Code
27mDesigning Even Larger (JavaScript) Applications
44mAvoiding the pitfalls of rebuilding software
17mHow to deal with technical debt in fast-paced environment