Legacy Code and Systems

Legacy code is often described as code checked into the system without a unit test. A popular definition from Michael Feathers, author of Working Effectively with Legacy Code.

The term “legacy code” is commonly used to refer to a codebase that has become increasingly difficult to maintain. There might be a number of reasons: complexity, hard to read, use of old apis or idioms. Maybe the original developers have left and their successors don’t understand the design choices that were made to get there.

The issue with legacy code is often made worse by a lack of reliable automated tests, so team members can’t easily tell if changes they make break the existing system.

Fixing Legacy code

Fixing legacy code does not come with a magic wand.

• Churn + Complexity - Look for the biggest pain points first - look for the files that change the most frequently, that also have high code complexity
• Time - Understand fixing this isn’t an overnight activity. Instead of taking a year off to fix all the problems, a more realistic approach - take at least 30% of the team’s time to work on remediation.
• Fence and Add Tests - Identify testable boundaries, start writing automated tests that prove the behaviour of the system inside the boundary is stable.
• Incremental Tidy Up - within the boundaries of passing tests, take small steps to improve.
• Pair or Ensemble Programming - a big problem with legacy code is that no one understands it. Pairing and Ensemble will spread knowledge throughout the team and reduce the time it takes to understand.
• Continuous Integration - Checkin Frequently and keep rerunning automated tests.
• Static analysis tools - can help to a limited degree, hile these tools can help identify complex code, they don’t tell you what do with the code.
• Microservices - another popular but limited tool. Splitting a large mess into smaller parts might seem beneficial, but remember that a mess divided is still a mess.

Finally have empathy for the people who wrote this code. It might even have been an younger version of yourself. The real magic is in putting the focus on improving the readability of the code and raising the bar on quality Sprint over Sprint.

Reinventing Existing Products – Big Bite vs Small Nibble Rewrites