Legacy code

Legacy code is code that still delivers value in production but is hard or risky to change, often because of missing tests, outdated technology or lost knowledge.

The word legacy describes a relationship between a team and its code. The code works, the business depends on it, and the people who maintain it are afraid to touch it. Michael Feathers, in his book on the subject, defines legacy code simply as code without tests. Without tests, nobody can know whether a change broke something.

Typical signs:

• The framework or the build tools no longer receive updates.
• The original authors have left and the documentation is thin.
• Small changes take long and cause unexpected regressions.
• New hires need months before they can work on it.

Example

A billing back office written in AngularJS processes every invoice the company issues. It has no unit tests, its build runs only on an old Node version, and two people understand the tax calculation screen. The application works every day. It is expensive to change, and that cost grows each year.

Common misunderstanding

Legacy is often used as a synonym for old or badly written. Age is a weak signal. A two-year-old application with no tests and no owner is legacy. A ten-year-old application with good tests and a supported stack may be perfectly healthy.

The label also tends to hide the value of the code. Years of business rules and edge cases are encoded in it, and any replacement has to reproduce them. For that reason the first step in a migration is usually to add tests and monitoring around the existing behavior, before changing anything. The AngularJS end-of-life options guide lists what a team can do with an application in this state.

Related terms

• Technical debt
• Strangler fig pattern
• End of life (EOL)