What Is Legacy Code?

The mere mention of needing to make changes in Legacy Code will make many software developers break out in a cold sweat. In our careers as programmers, we are likely to see more Legacy Code than non-Legacy Code. More often than not, we must work with existing code that has aspects of ‘Legacy’.

But what is Legacy Code?

Do we have an accurate definition? 

OK, let’s first recap some of the attributes of Legacy Code:

Very often, it’s code that has been around for years. Many different developers have worked on it – each with their own programming style. 

Legacy systems frequently have lost architectural integrity. There are no (or very few) discernable patterns. In the oldest and messiest legacy code, several abandoned attempts of reintroducing structure to a system compete with one another, ultimately making the code even more difficult to work with. In such legacy code it is nearly impossible to discern the behaviour it creates. 

Legacy Code is affected by the typical problems of Fragility and Rigidity—i.e. any program change may cause unexpected behaviour changes elsewhere in the system, and even minor feature changes require many code changes. Fragility and Rigidity feed off one another: If a minor feature request requires multiple code changes that in turn cause a cascade of undesirable behaviour changes in the system, then it’s no surprise software developers do not like to work with Legacy Code. 

It would be like working with someone who’s got a hair-trigger raging temper, and you don’t know what sets them off. 

So, we have a good idea as to what attributes Legacy Code possesses.

But can we form a helpful definition for Legacy Code from that alone? 

No, I don’t think so. 

Maybe we need to roam a bit further.

Micheal Feathers, in his fine book “Working Effectively with Legacy Code“, posits a different definition: 

“Legacy Code is code without tests.”

I like this definition. 

It is precise and actionable: We now know that the presence of a suite of unit tests distinguishes non-Legacy Code from Legacy Code. Here is where we need to focus our efforts if we want to end up with maintainable code. 

Another implication is, of course, that code need not take years to decay into its legacy alter-ego. On the contrary, we can write Legacy Code today simply by producing our programs without unit tests. Even beautiful, concise, reads-like-natural-language programming is instantly rendered ‘legacy’ if it is not also accompanied by unit tests describing its behaviour.