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?
Defining a legacy system
What is a legacy system? One says it’s an old system, another a system “received” from others or even a system that cannot be modified. Indeed, there isn’t a unified definition of legacy systems, but there is a set of indicators we could loot at. Let’s see some of them:
Lifetime
An “old” system, built relatively a long time ago, isn’t necessary a legacy. The lifetime is certainly an indicator, but not a definition.
Usefulness
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.
Obsolete Technologies and Hardware
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.
Maintenance
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.
Documentation
A few authors claim that a characteristic of a legacy system is lack of documentation. I completely disagree. In this way, the majority of modern systems would born as legacies. 😉
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.
Creating a legacy system
Specific decisions and actions, or the lack of them, collaborate in making legacies.
Don’t design properly
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.
Don’t refactor
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.
Conclusion
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.
