Every system old enough to make money is old enough to be embarrassing. The code is uneven, the person who wrote most of it has moved on, and the first engineer to look at it with fresh eyes says what fresh eyes always say: it would be quicker to start again.
It almost never is. I build software for a living, so a rewrite is usually the bigger job for me, and my advice is still to wait. Not forever, and not in every case. But as a first move, a full rewrite is the most expensive way to find out what your system does.
The old system knows things nobody wrote down
A system that has run a business for years is the only complete description of how that business works: the discount for one kind of customer, the rounding that makes invoices agree with the tax return, the invoice series that restarts on 1 April. Each was a request or a bug report once, and most live nowhere but the code.
A rewrite starts from what people remember to tell you. That is the requirements, not the business. The new system goes live, and the business rediscovers its own rules one complaint at a time.
A long time with nothing new
While a rewrite is underway, you pay for two systems and benefit from neither. The old one still needs fixes, because people still use it; the new one delivers nothing until it is ready. Months pass with no visible improvement, the people paying start asking what they are getting, and scope gets cut to hit a date. The new system then launches doing less than the old one did.
The ground keeps moving
The business does not pause for the rewrite. A tax rule changes; a branch opens. Every change has to be made twice, or the rewrite quietly falls behind the thing it is meant to replace. The finish line moves at the speed of the business, and the business is usually faster.
What to do first
Read it. Before anyone decides anything, someone should read the code, the database and how people actually use it, and write down what they found. That is how I run an audit and rescue: a written assessment with the fixes ranked by cost and payoff.
Measure it. “It is slow” and “it is a mess” are not findings. Which screens are slow, and how often? Which part breaks whenever it is touched? The pain is often concentrated in a small corner; in a database it is usually a handful of queries.
Fix the worst part. Then the next. Each fix ships, users notice, and each one teaches you more than a rewrite plan would.
Replace pieces behind a stable interface. When a part really must go, put a fixed boundary in front of it (an API, a database view, an agreed file format) so the rest of the system talks to the boundary, not to the old code. Build the new piece behind it, run both side by side, compare their outputs, then switch. Repeat, and the old system shrinks until what is left is small enough to rewrite cheaply or good enough to keep. It is usually called the strangler fig pattern.
When a rebuild is the right call
I am not against rewrites. I am against rewrites as a reflex. These are the situations where one earns its cost:
- The platform has ended. When the operating system, language or vendor underneath is out of support with nothing to upgrade to, there is no incremental path. When Symbian was discontinued, I moved to Android; no refactoring keeps software alive on a platform that has stopped.
- You cannot change it at all. No source code, no way to build or deploy it, nobody who can run it. You cannot replace pieces of something you cannot touch.
- It is small. If a careful rewrite takes weeks rather than a year, most of the risks above shrink with it.
- The business has changed underneath it. If the system models a business you no longer run (one company where you now have several) and every feature fights the data model, the old rules are not worth preserving.
- The incremental route was tried and measured. If you have fixed the worst part for months and each change still costs more than the last, that is evidence, not impatience.
Even then, rebuild the way an auditor would check it: keep the old system running, reconcile the new one’s output against it on real data, and switch over in pieces where you can.
The urge to start again is usually a wish to stop not understanding something, and a rewrite is the slowest way to get there: months spent rebuilding what you could have learnt in weeks of reading. So read it first. Measure it. Fix the part that hurts most. If after all that it still has to go, you will rebuild it knowing exactly what it does, which is the only way a rebuild goes well. And if it only needed a few good fixes, you will have saved the price of a system you already own.
