If you work with IT, certainly you already heard about “legacy systems”. However, unless you have searched about it by yourself, I doubt someone took the time to explain what it really means. As in many lingoes, people often just use it without really knowing its meaning and are ashamed of telling they don’t know what it is. So legends emerge. After all, we all born knowing such an obvious thing, isn’t?
An “old” system, built relatively a long time ago, isn’t necessary a legacy. The lifetime is certainly an indicator, but not a definition.
A system that isn’t used anymore is not a legacy system. A good indicator is a system that’s essential for the business and cannot be abandoned, even though sometimes people would want to.
A third indicator of a legacy system is its obsolescence. Some systems work on ancient hardware, such as mainframes, which components are costly and rare. Deprecated programming languages, development tools, protocols, database systems and data formats are also important to be considered.
Another tip about a legacy can be detected when all the original developers are retired or left the company, being difficult to replace the workforce. Actually, if people prefer to die instead of working on a software, probably there is a legacy system involved.
However, if no one knows the business rules behind it and it’s impossible extract them from the implementation, that certainly indicates a legacy system.
Specific decisions and actions, or the lack of them, collaborate in making legacies.
The main act that produces legacy systems occur just in its conception. A critical system, from business point of view, without a good design inevitably will become a legacy quickly, as soon as it’s deployed and people realize new features are hard to be added.
The system’s complexity grows when it’s modified to meet new requirements. We can call it “entropy”. When code is changed or added without any control, it becomes more and more unorganized and difficult to understand. Without refactoring and internal improvements of the architecture, it would reach a point where will be almost impossible to make any modification without break something.
A friend of mine used to say: “this system is like a short blanket, you cover your feet and it uncovers your chest, you cover your chest and it uncovers your feet”. Did your hear of cases when for each bug fix, two new bugs arose? I heard about a company that chose don’t fix a system because they feared it would not work anymore, since the consequences of changes were unpredictable.
We looked at various indicators of a legacy system, then a few items about how we, as developers, contribute to their appearing.
A more generic and broad definition of legacy system, which I learned from an advisor and professor, goes like this: from a point in the lifetime of a system, its architecture becomes complex enough to make the cost of maintenance higher than the cost of building a new one. There are some issues in this definition, but I won’t go into details. The main idea is: if the cost to add new features is a great constraint to the business, we have a legacy.
There is not absolute rule to define what a legacy system is, but such knowledge about this type of system surely help in management decisions and also in the development of new systems, since we’re able to take actions against the growing complexity in order to make system’s lifetime longer.