Measuring Legacy Systems for Technical Debt and Quality


Legacy Code

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

Get The Report "How To Reduce Technical Debt" For Free Now

Filed in: Technical Debt
  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
Jeff Cogswell
Jeff Cogswell Full Stack Developer
Jeff Cogswell is a Software Developer at Keypath Education and is responsible for producing high-quality, scalable, cloud-architected software and desktop applications. With more than 20 years of experience working in the software field, Jeff is an expert in scalable development using AWS, node.js, SQL and NoSQL.
Load more reviews
Thank you for the review! Your review must be approved first
New code

You've already submitted a review for this item