Agile Pain Relief Consulting

Scrum and Agile Training and Resources

Legacy Code and Systems

by

ALL0-9ABCDEFGHIJKLMNOPQRSTUVWXYZ
« Back to Glossary Index

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

Resource Links:

LEGACY CODE AND SYSTEMS BOOKS

See Also:

Approval Tests
Technical Debt




*Thank you for visiting the World's Largest Opinionated Agile Reference Library. This content is created and the links are curated through the lens of Agile Pain Relief Consulting's view of what is effective in the practice of Scrum and Agile. We don't accept submissions and emails to that effect are marked as spam. Book listings may use affiliate links that could result in a small commission received by us if you purchase, but they do not affect the price at all. From experience, this won't amount to anything more than a cup of coffee in a year.« Back to Glossary Index