by John Browne, on Aug 29, 2013 1:35:00 PM
Driving home yesterday I heard a story on All Things Considered about overflowing sewers in Miami. Since my college studies in microbiology had made me familiar with what actually happens after the big gurgling noise in the bathroom I listened with more than usual interest. Turns out Miami's water and sewer systems are overloaded and failing after years of neglect. The EPA estimates that around $125B is needed nationally just to repair existing water and sewer systems.
They're not sexy but try living without them.
What has this got to do with legacy code?
More than you might think:
On a slightly more sober note, there are some notable costs to legacy applications that only get worse over time:
- Maintaining legacy code can be expensive because there are fewer and fewer trained developers and the older development environments are inefficient and clunky
- Risks of running on unsupported platforms; those risks might be in security vulnerabilites or non-compliance sanctions (PCI, HIPAA, Sarbanes-Oxley)
- Poor scalability causing performance problems
- Lack of business agility.
Application modernization brings many benefits to the organization by extending the value of your investment in existing IP while avoiding the risk that replacing or rewriting applications brings.
Let's doubleclick on that sentence:
Application modernization: Why throw out perfectly good business value? Look, you've got old mossy apps that are still running. Everybody does. But the fact that they're still being used means they provide some value. And by this time probably most of the serious bugs are long gone. Why toss that if you don't have to?
Value of your investment in existing IP: You've paid for that code. It's done. It's tested, it's debugged. The finance department may regard it as a fully depreciated asset, but unlike trucks and copiers, which wear out, software doesn't get worse with age.
Avoiding the risk... I don't think I've met the developer yet who, looking at a piece of existing code, said, "Let's reuse as much of this as possible." Instead, I hear, "This is a stinking pile of crap. We have to completely rewrite it." I get it. Conceptually it's easier to raze and rebuild than to remodel. The problem is that the rewrite is so expensive, and the industry statistics on hitting budget and schedule for new software development are appalling. Finally, even the best software engineers in the world write somewhere between 20 and 50 new bugs per KLOC, so if your rewrite is 100KLOC you'll have between 2,000 and 5,000 bugs to find and fix. How fun.
We talk to customers every day who are struggling with this issue. What to do with this legacy application? Here's a few things to consider when you're facing the same question:
- How critical is the application to the organization?
- How good is the code?
- What would happen if it just went away?
- Can you replace it with commercial off-the-shelf software (COTS)?
- If you did, what customizations would you have to make? What features would you have to live without?
- What event or deadline is driving the need to modernize?
- What would happen if you didn't?
- How much and how often do you foresee changing the application in the future?
- What projects get delayed or cancelled if your resources are working on rewriting or modernizing this app?
- What's the relative priority of modernizing this app versus all the other legacy code in your organization's portfolio?
If it's reasonably good code with business value, and you will--at some point in the future--need to enhance or modify the app, then migrating the code base to a modern platform is probably going to be the best alternative. Especially in terms of time and cost. Especially if you use automated transformation tools.
Unless you work for a startup, you've probably got legacy code, and, like Miami's aging sewer system, sooner or later the antiquity of that code will reach a crisis point. Let's face it, when the streets are covered in poo, that's a lousy time to START the process of planning how to fix it.
