When a business develops software, new technologies eventually outgrow the software. But that doesn’t mean the software stops working, which is why businesses continue to use legacy software. In fact, after all the fixes and patches, the legacy software still gets used because it simply works, even if it means the users are forced to run older operating systems and older web browsers to use it.
But what is the impact of legacy code quality and technical debt on modern businesses?
Legacy code presents a special problem because on one hand, the software works. It’s been fixed, repaired, and touched up so many times over the years that it’s at a point that it rarely breaks down. It keeps grinding ahead, doing what it needs. Though it appears to work it doesn’t mean it’s not broken when put under the telescope. The bigger infrastructure includes modern operating systems, the latest versions of databases, and new devices. And therein lies the special problem: You have an old workhorse of software that’s aged well and has battle scars, but it’s slow and doesn’t play well with the newer systems.
In reality, the legacy code became a huge slice of technical debt the moment it went into production, simply by nature of time passing. But at the time it was unlikely that anyone saw these debts coming. The software was built to specification, and even built to be maintainable and enhanced — at least by 1990s standards, for example. Nobody could predict in 1995 the role the web and mobile devices and cloud systems play in our software today, twenty years later. The software simply wasn’t designed to work with such new technologies.
But now here we are. You have new software written, and you have old software you need to maintain, and, quite possibly, you have to integrate the old with the new. Most likely, your business model doesn’t provide room to toss the legacy code and rewrite it from scratch with modern tools. The cost is often more than the benefits. (Or is it? That’s something you need to weigh and measure carefully before immediately deciding one way or the other.) But you do need to retrofit the software with modern systems, and keep the quality up when measured against the newer technologies, and minimize the debt.
Yes, that debt may be quite high due to time passing, but you can actually pay off a good chunk of the debt. For example, you’re still dealing with source code that can be modified. And you’re dealing with newer technologies whereby many tasks are much easier. And you can write additional code that automates and integrates the old code with the new. But to make that happen, you need solid ways to measure your legacy code’s quality and technical debt as you move forward to make sure you’re doing it correctly. You need to measure the original code to find new problems; you need to measure the new code; and you need to measure the integration code, along with the overall picture.
Just because code is old doesn’t mean it has to be tossed. There’s a reason large software shops continue to reuse old code from earlier projects; it’s been tested and put through the wringer. But that alone doesn’t make it perfect. With modern measurement tools, you can find out where additional problems live, and what problems exist in the integration. And once you do this, then you can upgrade your code for a modern infrastructure that includes mobile systems, modern databases, virtual operating systems, new browsers, and more, all without throwing away the old legacy code. And in the end you’ll be confident your system is solid, thanks to the accurate measurements.
Learn more about Technical Debt – listen to Deloitte Consulting’s findings on Technical Debt across the industry.
The Deloitte Tech Trends report, it is chockfull of statistics, best practices and relevant case studies. The authors have combined some broad industry research with their own extensive field experience to produce this synopsis on the topic. Some of the things you will learn include:
- Multi-component defects comprise only 8% of all defects, but drive 52% of effort to fix
- How leading organizations have tackled technical debt and excess complexity
- The set of steps you should start within your technical debt reversal journey