Another definition from our mini-series: This time we look at the term legacy.
The term “legacy” has a negative connotation in IT, and stands for an old, somehow bad piece of software. In real-life, legacy has a completely different and often positive meaning.
Let’s start with a definition from dictionary.com:
noun, plural leg·a·cies.
- Law. a gift of property, especially personal property, as money, by will; a bequest.
- anything handed down from the past, as from an ancestor or predecessor: the legacy of ancient Rome.
So, a legacy in that sense is something we have inherited from our ancestors. For example, the great composer Wolfgang Amadeus Mozart left an incredible amount of (positive) legacy. In 2016 he even sold more CDs than any other artist, including Beyonce. If you dislike classical music, just take Elvis or Avici.
Apart from the horrendous legacy of tyrants and dictators, “legacy” is usually seen as something positive, valuable and worth remembering and keeping.
Legacy in software
In software, things are a bit different: “Legacy code” is often considered code that people don’t want to work with, that is hard to change or difficult to understand. Sounds quite negative, but… that’s only part of the story:
Legacy software is successful
As a rule, legacy systems are actively used, they earn money or perform important - they are in production. The owners of these legacy systems want to maintain or extend them, even if this is not always in the interest of the development teams concerned. In that sense, legacy software should be considered as being successful - otherwise their owners would have gotten rid of these systems a long time ago.
Legacy systems contain technical debt
What many legacy systems also have in common is that work on them usually takes longer than it necessarily should, i.e. there are sometimes considerable technical debts in legacy (see Managing Technical Debt, a whole book devoted to this topic).
Michael Feathers gave an alternative and very different definition in his famous and highly recommended book “Working Effectively With Legacy Code”:
Legacy code is code without tests.
Michael Feathers
In my opinion, this falls short in several aspects:
- Having automated tests does not mean “everything is great”. Even software with tests can be hard to maintain and change: Imagine an overly extensive test suite that does not test the important things.
- Even code without tests can be highly understandable and easy to change and enhance.
I prefer the definition by Adam Tornhill, “code with quality deficits”: Adams definition includes problems like high coupling, low cohesion, bad naming, missing tests, fragile design, lack of consistency plus all the other code deficiencies you can think of.
Additional risks with legacy code
Existing (legacy) code might be clear, concise, and understandble, but might:
- suffer from revision lock: it contains dependencies to frameworks, libraries, or even hardware that is no longer supported or available. Consider systems written in clean code that depend on certain libraries only available for Java 6 (which reached its end-of-public-updates in 2013…).
- depends on data structures no longer reflecting current requirements, but cannot be changed due to organizational or legal constraints. Data is often harder to change or maintain than code.
To make things even worse – the source code of your legacy system might have been accidentally deleted or otherwise gotten lost (did you ever hear of a hard drive crash and the backups could not be used…)
Legacy code is code you need to change…
Nicolas Carlo came up with a nice explanation of legacy code which summarizes many of these aspects:
Legacy Code is profitable code you’re afraid to change.
Nicolas Carlo
Nicolas maintains a website dealing with legacy code.
Conclusion
There is no single answer to the question what legacy code is.
Legacy in real-life is often something positive or valuable we inherit from the past. Legacy code is a double-edged sword though: It can have a multifaceted past, but earns money (positive). It might have code quality problems, and current developers or maintainers might have difficulties understanding it (very negative).
Legacy is our normal. Throwing away large systems that have grown historically or hysterically over a long period of time (aka big bang) is far too risky in the vast majority of cases and thus not a real option. We should rather value the legacy of many hundreds or thousands of days of development time, and dare to continuously improve them in small steps despite high technical debts in these systems. An exciting task for the role of “software architects”!
Other posts in this “series”
If you have an IT-relevant term that you would like to have explained here, please let me know.
Image credit: The Mozart portrait has been drawn by Johann Nepomuk della Croce and is Public Domain. Source: Wikimedia Commons.