Rewrite or repair: how to decide for existing code

Generally, repairing step by step is safer than rewriting everything. A full rewrite is tempting because it promises a clean start, but it takes longer than planned, and meanwhile your product does not move forward. It is justified in specific cases, which can be identified.

The analogy: the house or the empty lot

Your house has flaws: a leak, old wiring, a poorly designed kitchen. Should you tear it down and rebuild? Rarely. You check the foundations first. If they are sound, you renovate room by room and keep living there. If they are cracked, renovating costs more than rebuilding.

With code it is the same: everything depends on the state of the foundations.

Why a rewrite is riskier than it looks

• Existing code contains invisible decisions. Special cases, bug fixes, business rules learned over time. A rewrite forgets them, then rediscovers them one by one, in production.
• It is long, and the outcome is uncertain. Meanwhile, the old version must be maintained in parallel.
• The new code will have its own debt. Without a more rigorous method, you fall back into the same problems.
• Your users see nothing. For weeks or months, they get nothing new.

When repairing makes more sense

Repairing (the technical term is "refactoring": reorganizing the code without changing what it does) is a good choice when:

• the application works and serves its users;
• the problem is localized: one fragile part, not the whole;
• the overall structure is understandable;
• you want to keep shipping features during the work.

When a rewrite is defensible

• The foundations are unsuitable: the chosen technology cannot deliver what the product needs to become.
• Nobody can change the code without breaking something else, and nothing makes it safe to do so.
• The product has changed nature: what was a prototype has become a service you want to grow.
• The technology is abandoned and no longer receives updates, including security ones.

Even then, a rewrite can be done piece by piece: you replace one part at a time while the rest keeps running.

Five questions to decide

1. Does the application serve people today, despite its flaws?
2. Are the problems concentrated or everywhere?
3. Do the foundations (structure, data, technologies) support what you want to build?
4. Do you know what the current code does, including in special cases?
5. Can you afford to ship nothing during the rewrite?

If you answer "yes" to 1 and 4, repairing is generally preferable. To gauge how much your code slows you down, see technical debt.

The middle path

You can also stabilize first, decide later: add tests on the critical parts, fix the most urgent flaws, document. That restores visibility, and the decision to rewrite, or not, is made with facts rather than a hunch. If you have just taken over the code, see also taking over a project left by a freelancer.

Remember

Do not rewrite because you dislike the code: rewrite only if the foundations cannot carry what you want to build. When in doubt, stabilize first, then decide with facts.

And for your product?

If you hesitate between repairing and starting over, our project takeover support begins with an assessment that lets you decide on concrete elements, with no bias toward either option. We can talk it over in a 30-minute call.