Full Rewrite Versus Incremental Refactoring
TradeoffStaffPrincipalUpdated
A revenue-critical Rails app has 400,000 lines, 30% test coverage, and twelve engineers. Leadership expects new features every sprint while the code is cleaned up.
Short answer: Incremental Refactoring. Refactor in place, adding tests around each area before changing it, so the product keeps shipping and every improvement reaches production.
The Two Options
A
Full Rewrite
B
Incremental Refactoring
Drill This: Your Pick First
The Better Pick
Option B
Incremental Refactoring
Refactor in place, adding tests around each area before changing it, so the product keeps shipping and every improvement reaches production. A rewrite has to rediscover years of edge cases from code with little test coverage, and it freezes features for a year or more while the old system keeps changing underneath it. Rewrites of this size routinely run long and launch with regressions.
When the Other One Wins
Full Rewrite
When the platform itself is the problem, such as an unsupported runtime or a framework that can't meet a new requirement, a scoped rewrite of the affected part beats patching a dead end.