Evan's Blog

# Dealing with Legacy Code and Technical Debt

Legacy code and technical debt, are two topics that go hand in hand.

# Definitions of Legacy Code and Technical Debt

When you mention legacy code, many people assume that you're talking about really old code that was created decades ago, but that's not always the case.

There are many different definitions of legacy code, with the most popular one being by Michael Feathers, which is simply that legacy code is code without tests.

There are also said that legacy code is code without sufficient communication artifacts to explain its intent. And while tests are excellent communication artifacts, there are other communication artifacts, such as written documentation, and guess what? The code itself is also a communication artifact.

  • Legacy Code
    • Usually older code, but not always
    • Code without sufficient communication artifacts to explain its intent
    • Tests are a very effective communication artifact
    • So are other forms of documentation, including readable code

The Technical Debt is used to explain the impact of choosing to cut corners instead of following best practices.

If you don't pay down the debt, the interest will continue to accumulate and soon, all of your efforts will be focused on making interest payments and very little will go towards paying down the principal.

# Review the Technical Debt

Here are some common technical debt challenges:

  1. Limited familiarity with all(or most) of the code
  2. Not sure where to start
  3. No one who can answer questions

To handle this, let's learn how to build and run the project first. Usually, try to find resources from:

  • README and other text files
  • Project wiki
  • Issue tracker

You may find that:

  • Surrounded by past decisions
  • Some code could be better
  • Some code will be confusing

And as you move through the historical artifacts that have been left behind for your discovery, it's important to not judge the people who used to work on the project. When you inherit an older code base, it's important to realize that it's now yours. You have the power to make the code better. The project is yours now, own it.

# Handling the Technical Debt

Automated tests are vitally important for making improvements to our code basis. They act as a welcomed safety net, allowing us to make the changes that are needed to reduce technical debt without having to worry as much about unintended consequences.

First, Let's evaluate the Automated Test Suite. Here are some things we can do:

  • Add a test suite, if one is missing
  • Discover how to run the tests
  • Address each failing test
  • Increase coverage as needed

Now, Let's pay down the technical debt. First, remove noise and distractions:

  • Commented-out code should just be deleted as soon as you see it.
  • Use IDE to reformat poorly formatted code. Remove any distractions you find.

Technical debt is not something that you just address once and stays gone forever. Instead, it's a lot like weeding a garden. After you take the time to remove all of the weeds in your garden, they will not stay gone forever. The weeds will come back. Slowly at first, but then before you know it, your garden will be overrun again. The best way to address this is to spend a little bit of time weeding your garden every day

← Secure Coding →