You’ve been here before. A new framework drops. The blog posts are glowing. The conference talks are packed. The message is clear: the old way is broken, and this shiny new thing will fix everything.
You’re tired. You’ve shipped this rewrite before. You’ve migrated from Angular to React to Vue to Svelte. You’ve watched your team spend months rebuilding something that already worked, while the actual product rot sat untouched. You’ve felt the sigh of a senior dev who knows this is just another cycle.
The tech industry doesn’t reward building things that last. It rewards building things that are new.
That’s not a bug. It’s a feature of the incentive system. Engineers get promoted for launching. Startups get funded for disrupting. Conference talks need fresh material. And the easiest way to look like a hero is to declare the existing stack a relic and start from scratch.
But here’s the twist: this isn’t just ego or incompetence. It’s a rational career strategy. When your performance review asks about ‘impact,’ rebuilding a stable system from scratch counts more than maintaining it. The person who rewrites gets the promotion. The person who keeps the lights on gets a ‘steady performer’ rating.
We have created a system where the most efficient path to personal success is to create systemic waste.
I saw this firsthand at a company where a team spent six months rewriting a perfectly functional backend in a new language. The old codebase had 10 years of edge cases, bug fixes, and institutional knowledge baked in. The new one launched with 80% of the features and a dozen new bugs. The team got a standing ovation for ‘modernizing.’ The maintenance team got a backlog of tickets.
This isn’t about technology. It’s about incentives. The ‘not invented here’ syndrome is often painted as an ego problem, but it’s a career problem. The person who invents gets rewarded. The person who inherits gets forgotten.
And so the churn continues. We keep reinventing the wheel because people are rewarded for the act of invention, not for the quality of the ride.
The next time you’re asked to rewrite a stable system, ask yourself: is this for the product, or for the resume?
The answer reveals everything about the culture you’re in. And it tells you whether you’re building a legacy or just another line on a performance review.
FAQ
Q: Doesn't rewriting sometimes make sense for technical reasons like performance or security?
A: Sometimes. But in most cases, the performance gain is marginal compared to the cost of losing institutional knowledge. The vast majority of rewrites are driven by novelty bias, not necessity.
Q: What should I do if my boss wants to rewrite something that works?
A: Ask the hard question: 'What concrete problem does this solve for the user?' If the answer is mostly about developer experience or resume value, redirect the energy to shipping features or fixing actual bugs.
Q: Isn't there value in learning new technologies?
A: Yes, but learning should not come at the expense of the product. The best engineers learn on side projects, not on production systems that serve real users. Separate learning from building.