When working with legacy code, the temptation to start from scratch can be strong. It’s natural to want to clean up the mess and create something shiny and new. However, rewriting code can often do more harm than good. It comes with high risks and costs, and it’s important to weigh the benefits carefully.

In his book The Hard Thing About Hard Things, Ben Horowitz states, “The primary thing that any technology startup must do is build a product that’s at least ten times better at doing something than the current prevailing way.” This same principle applies to code rewrites—if the new system isn’t significantly better, then the effort isn’t worth it.

Here’s why rewrites can be dangerous:

  1. They destabilize the codebase: A rewrite can introduce new bugs and make the code less stable, especially if the old system worked reliably.
  2. They come at the cost of new features: When time is spent rewriting existing code, it’s not spent on adding new features that could benefit users.
  3. Coding standards matter: Even if certain standards seem outdated or unnecessary, they are there for a reason. Diverging from established patterns can make code harder to read and maintain.

Instead of jumping into a full rewrite, consider incremental refactoring. This allows you to clean up code without disrupting the entire system. When rewrites are necessary, ensure that they provide significant improvements to justify the time and effort required.