The big Rewrite
summary
Argues that full rewrites routinely fail: estimates run long, legacy edge cases reappear, and users demand feature parity so the new app must match the old from day one. Rewrites create double work (port fixes) and morale hits; historical example: Netscape loses ground after a multi‑year rewrite. Recommends incremental refactoring, fast reliable CI with CI under five minutes, tests-first bug fixes, and selective module extraction and feature toggles so risky parts can be replaced safely.
AI-written summary · about
chapters (7)
- 0:00Start
- 0:56Part One the Brave Step
- 5:17Feature Neutral
- 5:57Backlog Refinements
- 21:41The Boy Scout Rule
- 28:11Stop Fixing Bugs
- 32:45Legacy Code
related talks
36mHow to sell a big refactor or rewrite to the business?
33mTaylor’s Guide to Big Rewrites
49mHow to sell a big refactor or rewrite to the business?
42mHow to sell a big refactor or rewrite to the business?
51mHow Your Organization is Killing your Software
42mSo You Want To Rewrite That...
31mLessons learned from refactors and rearchitectures
55mAre Rewrites always a Bad Idea?