The term legacy is used quite broadly in software engineering. Typically it’s used to refer to a system or technology any reasonable person should avoid as much as possible. However, if we go deeper into trying to understand what legacy in software means we can uncover some more interesting insights.
Legacy as value
In Merriam-Webster dictionary legacy is defined as:
something transmitted by or received from an ancestor or predecessor or from the past
As legacy is something transmitted by an ancestor it means that it has some value (or at least had for the ancestors). Similarly having a legacy system means it’s been in use for a while therefor has been valuable for the organisation for some time. Treating legacy as something purely negative is discarding the fact it can contain many hidden gems.
In real world each generation builds on top of the previous one. The same way in software systems we may have layers built on top of each other. When we add new logic we often treat the existing business rules as a black box or use “the least possible change” strategy. Unfortunately this introduces a lot of accidental complexity. This does not mean the value is not there — it can just be that the organisation has lost knowledge of it.
Legacy as lost knowledge
Often when engineers talk about legacy codebase they mean something that’s badly written or lacks rigid test suite (the latter typically leads to the former). Indeed, badly written codebase makes it much harder to understand existing business decisions and system logic. But there’s more to it.
There’s a natural tendency of losing knowledge about any system as the original authors move on to “greener pastures”. The longer some part of the system stays unchanged the more likely it is that it’ll become legacy (something we lack complete knowledge) over time.
It’s this lack of knowledge that leads to the use of outdated technologies in such codebases. The less the team knows about the system the less likely it’ll keep all the used libraries and dependencies up-to-date.
Legacy as the result of handover
A “great” way how to instantly transform codebase to legacy is handing it over from one team to another.
No matter how well written and documented the system is or how thorough handoff training is done. Nothing can compete the tacit knowledge gained by building it.
In the worse case this can be result of organisation’s software engineering process where there are separate teams for development and maintenance. However, it can also happen in more hidden forms where a team builds an initial solution and then hands it over to another team for further development.
P.S. Interested to join us? We’re hiring. Check out our open Engineering roles.