Legacy code, technical debt and software quality

Legacy Code in Software Quality

Last week in Toulouse, France, a century-old monument weighing over 1000 tons of stone was moved to facilitate urbanization work. Disassembly was not possible without damaging the building, so it was moved instead, involving meticulous engineering.
What does this story have to do with software quality and legacy code? Well, some software projects do have large code bases, part of which can represent tens of thousands of lines, or are so old that you can’t modify them without breaking something. It is not uncommon that developers have to deal with legacy code, and develop convoluted designs to work with it.

So keeping the history part of the present is the common theme here. How can we deal with legacy code, how does it impact new development, and software quality? Let’s see how a software quality monitoring tool such as Squore answers these questions.

Dealing with legacy code

A software project is naturally constantly evolving, by adding functions, refactoring classes, and modifying algorithms. Squore’s static code analyzer keeps track of these changes, and makes sure you know what changed, and when.

The following chart helps understand the source code history visually with colored layers:

source code history, legacy code, new code, trend over time
  • The bottom gray layer represents the legacy code files, the ones the project started with.
  • On the top layer: blue modified legacy files
  • Above the “surface”, purple layers: new files. The lighter the shade, the longer these new files have remained untouched.

Keeping track of historical code, and updating history as development continues is the key to being able to efficiently focus on the code you really want to work on.

Legacy code and new development

With tagged code (Legacy or New, Stable or Active), you can easily filter it by ‘Artefact Status’. This means that you can control the scope of your analysis. For example, you can see below the same complexity heatmap chart, for all 1021 functions of a project, or just the 6 newly introduced functions.

Tagged code (Legacy or New, Stable or Active)

In addition to these visual and navigation aspects, Squore also integrates history into the technical debt computation.

Typically, the technical debt is going to evaluate how costly it would be to fix all issues for all code (legacy and new).
But we can also learn how much it would cost to fix yesterday’s commit, if we only consider the modified code. This is valuable information, because it is much easier and more efficient to fix recent code that is fresh in our memory than old code potentially more difficult to maintain.
It doesn’t mean we ignore old code, of course, but that we can choose to focus on code depending on its tags.

Software quality on legacy code

What can we do to integrate sometimes bulky legacy code in software quality monitoring and not drown under millions of rule violations when we run code checkers on the whole code?

Using Squore’s ‘Legacy Components’ flag when creating a project is useful when you don’t want the legacy code to interfere:

  • All rule violations (aka ‘findings’) found on the code are considered as ‘legacy’, and will be automatically ‘relaxed’ as such.
    These relaxed finding are still there, but won’t participate to standard compliance metrics and indicators
  • The side effect being that as the project evolves, new findings will be easy to track and review, whatever their origin (from new code or modified legacy code)

In the example below, we created a simple project with the ‘Legacy Components’ flag, resulting in 80 relaxed findings. With the next development iteration, 3 new findings appeared and can be reviewed.

Of course, you can also integrate legacy code in the project’s software quality monitoring. Then use features such as criticality filtering or test analysis to pinpoint parts of the code needing attention.

Conclusion: How to deal with legacy code

History is important, and legacy code needs to be part of the software quality monitoring process. By combining the code evolution analysis with quality indicators computations, tools like Squore can help identify where to act, and why.

As a final example, this chart shows the technical debt, or cost to fix issues, depending on the code’s historical tagging

  • The gray unchanged legacy code technical debt gradually decreases to almost zero.
    This means that the remaining untouched legacy code has very few critical issues
  • However, there’s something wrong.
    The blue area represents the technical debt for the changed legacy code.
    Instead of staying horizontal, this level increases, which means we have modified our legacy code, and introduced additional technical debt into it
  • As for the purple areas, they tell the technical debt story of our new code.
    It is not uncommon to see this level rise, but we should address it anyway.

Further readings


Legal Notice

This text is the intellectual property of the author and is copyrighted by coderskitchen.com. You are welcome to reuse the thoughts from this blog post. However, the author must always be mentioned with a link to this post!

Leave a Comment

Related Posts

What is software quality for a developer? - Coders Kitchen
Flavien Huynh

What is software quality for a developer?

Software quality can be tricky to evaluate, some say it is something you only recognize when you see it.As for quality for development, coming from

Find and filter relevant source code violations
Camille Raymond

Find and filter relevant source code violations

Why would you need to filter relevant source code violations? Aren’t all code violations important? And what does “relevant” mean anyway?Speaking of good quality habits,

Maintain Software Quality Coderskitchen
Andreas Horn

How to maintain software quality?

In my previous blog post “What is software quality and how to measure it?” I have explained what quality is and how we can measure

Software Quality Metrics Coderskitchen
Flavien Huynh

Software quality: From metrics to habits

There is more to software quality than preventing bugs. It also gives us the opportunity to reach better code. From the different levels of quality

Hey there!

Subscribe and get a monthly digest of our newest quality pieces to your inbox.