The full legacy rewrite comes back into style from time to time, every few years. It always offers the same sell: burn down that messy old system, build a shiny new one, and begin again. And it nearly always concludes the same way: overdue, over budget - and frequently inferior to what it supplanted.
This dangerous notion has just been unwisely dressed up in the garb of feasibility by AI. And that's something engineering leaders should be prepared for.
The seductive new argument
The reasoning sounds compelling. We have an AI agent that reads the old system at a speed no human can match. It can write huge sections of new code in a fraction of the time it did previously. But if speed of writing was the barrier, and AI removes that barrier - why not finally execute the massive rewrite?
Since speed of writing was never the issue.
What actually blocks a rewrite
The complete rewrite has been a failure for thirty years, and the reason involves next to nothing about how fast you type code.
Well, the best requirements exist only in the running code - undocumented and long since corrupted by Miller's law, understood only as an implicit collective knowledge.
The edge cases that keep customers happy are invisible until one breaks.
You cannot stop the business for 1-and-a-half years while reconstructing something that is already functional.
The time that it takes the rewrite to execute gives the old system all sorts of time to continue changing underneath you, so you are trying to hit a moving target.
Most big-bang rewrites never complete or deliver something worse then in-situ. These causes are untouched by AI. Not meant to just generate code faster, it takes you to the same cliff earlier but with more code to throw away when you tumble off.
The approach that works
The alternative is not fresh-faced, and that precisely why its credible. It is the strangler-fig pattern, but in sharper tools.
Instead of a Big Bang Replacement, you grow new AI-native modules around the existing legacy core. New modules gradually inherit the behaviour they take over, one slice at a time. One chunk at a time, the borderline between what is old and what is new becomes more dense. The whole time the legacy system continues to execute. And then one day the final slice crosses, and you turn off the old system without enduring a single heart-stopping cutover.
What we will have instead is a number of very small, reversible steps rather than one huge, irreversible jump in migration.
Two things that keep it safe
It works if you observe two disciplines - then strangler-fig.
Extract the tribal knowledge first. Get the undocumented rules out of people's heads and the existing behaviour into an indexed, searchable for both humans and agents to use before you touch the old code. But if you modernize your gut without understanding what they did, then bugs you never even realized existed will faithfully reappear in your code. This step is one of a few places where AI assists quite a bit: reading and abstracting a large legacy systemis exactly the type of work it excels.
Protect the seam with an anti-corruption layer. These new modules are quick and feed off of specifications. The legacy modules are slow moving and have long, brittle dependency chains. You put an explicit contract between them, with both sides tested. This layer prevents repetitive work in the new pace from breaking old-work assumptions, and prevents previous constraints from choking out novel-new work. And without that, the two halves bleed into each other and you get half-assed at both of them.
Where AI fits
AI is central to this and it's worth being precise because the temptation is obviously to over-reach.
AI accelerates the safe path. It reads from the legacy system, writes the new modules, and auto-generates the contract tests that safeguard the seam. It changes the speed of how quickly work moves inside the incremental approach.
But all it does not do is make a safe path unsafe. However, a big-bang rewrite that is generated by some AI is still a big-bang rewrite. After some point, the increased speed simply enables you to fail faster.
Before you choose a framework
When modernization comes to the roadmap, instinct is to go immediately to technology decisions: which language, which framework, which platform. The first question has nothing to do with technology.
Before you go ahead and replacing it, have you harvested what the old system actually knows?
No comments:
Post a Comment