When I first started consulting, I tried to specialize in Legacy System Rescue. I quickly learned that this is terrible positioning because Legacy System Rescue isn’t an Expensive Problem. Jonathan Stark defines an Expensive Problem as a problem that someone would like to spend a lot of money on to solve right now.
Legacy System Rescue is certainly a Big Problem. Everyone agrees that a buggy system that makes development slow and painful is bad. Errors in production are bad. Spending time and resources to mitigate production outages are bad. But there is no immediacy. There’s no reason to spend a lot of money right now instead of waiting until the next feature ships, or the next quarter. Letting things go just a little bit longer is usually why the system needs a rescue.
Hiring someone like me to come in, analyze the codebase and find a way to untangle the mess is a lot of work. Fixing bugs and making it easy to add new features is a low leverage situation. It takes a lot of time by highly skilled developers. Highly skilled developers in low leverage situations makes Legacy System Rescue an Expensive Solution. It will probably pay off for the company, but no one department is going to get enough value from fixing the legacy system to cover the costs. The ROI gets worse when you factor in the resentments of the developers. Bringing in an outsider to judge their work and dictate fundamental changes doesn’t fill people with joy.
Combine the two and you have a Tragedy of the Commons – a Big Problem that requires an Expensive Solution. What you don’t have is a business case to spend a lot of money, right now, to fix things.
You won’t pay me to rescue your legacy system because paying a lot, right now, for the solution is worth less to you than living with the problem.
