Things You Should Never Do, Part I (2000)
Rewriting a large software system from scratch is often seen as a tempting escape from messy legacy code, but commenters argue it usually underestimates the value embedded in the existing system and the time required to reach feature parity. Many emphasize incremental refactoring, strong tests, and documentation as safer paths, while acknowledging rare cases where code is so broken, requirements or technology have shifted so much, or performance constraints are so severe that a full rewrite can be justified. The conversation highlights the psychological appeal of greenfield projects, the business risks of stalled rewrites, and the need to distinguish small, rewritable codebases from mission-critical systems with millions of lines of code.
Overall sentiment toward wholesale rewrites
- Many commenters still agree that full rewrites are usually risky and often driven by psychology rather than necessity.
- Others argue that in smaller systems (tens of thousands of LOC) or truly pathological codebases, starting over can be the most pragmatic choice.
- There’s criticism of treating “never rewrite” as a universal rule; context and scale matter.
Why rewrites are so tempting
- Greenfield work is more fun; you avoid legacy constraints, operations pain, and messy history.
- Developers often believe they can “do it right this time,” armed with known requirements and hindsight.
- It’s easier to read your own style than others’, so the existing code looks worse than it may be.
- Rewrites can restore a feeling of autonomy and control, sometimes unconsciously.
Arguments for refactoring and incremental change
- Incremental refactoring preserves a working system, lets you ship continuously, and reduces risk.
- Removing dead code, isolating bad areas, and gradually improving architecture are seen as more sustainable.
- Comprehensive tests and trustworthy documentation significantly reduce the urge to rewrite by making change safer.
- Some compare refactor-vs-rewrite to reform-vs-revolution: revolutions usually end badly, but refusal to reform also leads to explosions.
When rewrites may be justified
- When the existing system is an “angry monolith/obelisk” where changes unpredictably break production and velocity has collapsed.
- When much of the existing functionality is no longer needed, so the new system is substantially simpler.
- When the original language/framework/architecture fundamentally blocks required performance or evolution.
- When code quality is “type two bad”: no structure, no source control, single enormous files, copy-paste chaos.
- Several report successful 50–100K LOC rewrites done by experienced teams deeply familiar with the domain.
Failures, scale, and organizational factors
- Large, multi-year rewrites often stall: teams end up maintaining both old and new systems in production.
- Examples are given of big-company rewrites that languish, second-system overdesign, and teams that simply can’t execute a complex greenfield replacement.
- Some note that rewriting can be a stealth career move: start the rewrite, enjoy greenfield coding, leave before support and hard compromises arrive.
Other themes
- Debate over whether code is harder to read or write; most agree deep understanding is the hard part.
- Frameworks are discussed as a way to standardize idioms and ease onboarding; others counter that frameworks can also be bad and aren’t a universal solution.