And maybe that’s fine
Everybody has a legacy application that one is too afraid to touch. This is accumulation of years of undocumented decisions, shifting business priorities and lost knowledge as people leave the project. It’s a potato that is getting hotter with each release cycle.
And by now, I am sure someone has asked you to “fix it with AI”.
If only it’s that easy.
Too Far Gone Link to heading
I have been to companies and seen legacy applications that are in a complete state of tragedy. Junior developers don’t understand the code, spends the first half of the sprint printing debug statements to figure out the relevant logic that supports business operations. Product managers have long lost the trail of feature decisions and rationale documents. Many features are obsolete but no one knows which ones. And then there are outdated documentations that adds rocket fuel to this dumpster fire of confusion.
In some cases there is a renewed business priority to enhance or to re-architect these applications, teams scramble to try to get the complexity under control. The business typically assigns the full ownership to the engineering organization - “it’s a code issue, so IT should fix it.” But this cannot be done without the business and product insights.
When I get all the different stakeholders in the same room (probably for the first time in a long while), they realise the state of despair they are in.
This is not the case for every major modernisation, but I have witnessed this enough times.
Fixing may be Unnecessarily Expensive Link to heading
There are two options here.
The first one that gets discussed is how to fix this. How much more manpower do we need to allocate; how far to extend the timeline; how to rediscover the lost knowledge? Even with the help of AI, this a high effort, long timeline process. Feeding hundreds of thousands of lines of code to the GenAI model quickly creates confusion in the context, resulting in low accuracy and less relevant responses. Additionally, while the source code is the best source of truth, not all peripheral information is documented in code. While AI can accelerate this process to an extent, it still requires significant human effort.
This is typically the only approach teams consider. Traditionally, the cost of writing software is so high, it makes sense to fix and refactor the existing system. But now with generative AI, we have a second, more cowboy option - to rebuild rapidly from scratch.
Rebuild from Scratch on Existing Data Link to heading
The first step is to do a business requirement discovery. There are likely features in the legacy application that are now redundant and no one is using those anymore. The product owner needs to re-establish the business objective and priorities, and work with the product manager to define and scope the product requirements. If the legacy application is sufficiently modularised based on business process boundaries, we can leverage on reverse engineering using GenAI to rediscover the implemented capabilities from the source code. Then, the team can decide what to remove and what to add.
**Having a****clear business objective and product requirement based on the legacy application lays the key foundation for an AI-driven rebuild following a methodology like the AI-Driven Development Lifecycle**. This understanding and alignment between stakeholders is key to verify the behavioural correctness of the rebuild.
The second step is to evaluate existing user data and re-use the current data structure and schema without major overhauls for the rebuilt system as much as possible. This helps to ensure business continuity. The data from the legacy application is the extension of the source of truth from the source code. This time, the data needs to be decoupled with the business logic to ensure long term adaptiveness to new changes and requirements. Eventually, we should also aim to remodel the data based on the new software architecture.
Once there is clearly documented requirements and existing data, it becomes easier to guide the AI in the development process and also to validate the behaviours of the new build.
After all, we have always been retiring unmaintainable code bases and rebuild from scratch. I used to think this is a huge waste of effort, but it doesn’t have to be anymore. From easily half a year of dedicated engineering effort, leveraging AI effectively could reduce the timeline to mere weeks. So, why not? What do you think?
This post was inspired by a conversation in a taxi in Tokyo with Janos Schwellach, Atsushi Fukui-san and Masao Kanamori-san as we bring the new method of software delivery to the world.