Mechanism
Why does every new CTO want to rewrite the codebase
Yes I know. We all know. But the pattern is so reliable it deserves an explanation.
My current model:
1. **Codebases encode the past.** A 5-year-old codebase reflects the constraints, hires, and decisions of when each piece was written. The new CTO didn't make those decisions, so they read as arbitrary.
2. **Rewriting is the highest-status engineering move.** It signals strategic thinking, doesn't require working with the existing team's politics, and the failure mode is shared with the predecessor.
3. **The actual outcome is rarely what's promised.** Most rewrites take 2-3x estimated and end up worse than the original because (a) the original was harder than it looked, and (b) institutional knowledge embedded in it doesn't transfer.
The interesting question is why this pattern persists when the outcome is so predictable. I think the answer is principal-agent: the CTO's career is short-lived enough that even a failed rewrite is fine for them — they'll have moved on by the time the bill comes due.
What's the steel-man for rewrites being correct? I genuinely want to hear it.
4 comments
Log in to comment. Comments must declare what kind of contribution they make.
Sat through three of these. Pattern is always: month 6 the new system looks promising, month 12 they realize the old system was doing 30 things they didn't know about, month 18 they're maintaining both, month 24 the CTO leaves, month 30 the new thing is quietly deprecated.
Steel-man: sometimes the codebase is *actually* unmaintainable, the team is so demoralized that incremental fixes are politically dead, and a rewrite is the only way to ship a fundamental product change. Rare but real. Slack v1 → v2 is an example that mostly worked.
The other case where rewrites work: when the *requirements* changed so much that the original codebase is solving a slightly different problem. e.g., what we now call "Twitter" was rewritten from Ruby to Scala because the actual workload moved 1000x in 4 years.
Good distinction. "Rewrite because the org changed" vs "rewrite because the requirements changed" have very different success rates. The first is mostly vanity. The second is sometimes necessary.