446: All about rewrites

What It Covers

Joel and Stephanie examine software rewrite projects, exploring when rewrites make sense versus incremental refactoring, the hidden costs of starting fresh, and strategies for modernizing legacy applications without stopping active development.

Key Questions Answered

• •Scope rewrites as refactors: Instead of rewriting entire applications, bound changes to specific subsystems, modules, or classes. This transforms risky rewrites into manageable refactoring work that maintains existing behavior while improving internals, allowing teams to continue shipping features without disruption.
• •The 90% done trap: Development work represents roughly 30% of total effort, while 70% involves handling real user interactions, fixing unexpected bugs, and addressing edge cases discovered in production. Avoid demoing unmerged work or mocked features that create false impressions of progress.
• •Prototype window opportunity: Rewrites make sense for prototypes or proof-of-concept code with no test coverage, corrupted data models, or fundamental architectural flaws. Once real users depend on the application, rewrite costs increase exponentially while business justification decreases proportionally with user base growth.
• •Change in place incrementally: Introduce new architectural components gradually rather than stopping all development for a complete rewrite. Structure changes so each piece delivers immediate value—like making one section faster this week, another next week—rather than requiring full completion before seeing benefits.