On the roots of Legacy Systems

Legacy systems are the major cause of expenses in the Information Technology world. Nonetheless, they are ignored or underrated, most of the time… until people are faced with a very critical situation that threaten their business.

Legacy systems show their deep nature when they resist to modification and evolution, typically because every effort spent in the attempt to change a component breaks almost every other component in the system. In that moment, the overall design is so deteriorated that any modernization initiative tends to cost more than the initial development expenditure. This is a price that most organizations are not willing or able to sustain.

The only real cure is early, preventive maintenance.

In order to successfully maintain software systems by controlling the amount of legacy code, it is important to understand the primary root causes of this phenomenon. Legacy systems are the result of the inability of controlling the technical debt inside software projects. Such debt originates from few factors, some of which are merely technical whereas others are more organizational-wide [Seacord et al., 2003]:

• Complexity. Most commercial systems double their base code in less than seven years. Architecture and detailed design decisions are rarely documented. People working on these projects are subjected to high turnovers. New coworkers are trained very quickly before they start to be operative. Requirements and the overall problem domain are not properly investigated. Finally, almost no effort is spent measuring and controlling the amount of technical debt added every year. Such issues produces an erosion of the software systems that can be clearly observed by measuring the increase of both procedural and structural complexity on a regular base. All these aspects together make also the software inscrutable over time, so it becomes prematurely aged. In a single sentence: a legacy system.
• Software technology and engineering processes. There is a tension between technologies and processes. Technologists consider software engineering irrelevant in front of programming languages, operating systems, frameworks and the like. On the other hand, even the smartest process does not guarantee the success of a product in the business context, preventing the premature obsolescence or assuring a sustainable level of maintainability. These two complementary perspectives are separated by a large chasm when they should instead be very cohesive. To succeed in preventing the legacy problem, organizations need to fully understand the theory behind engineering processes, the inner details of software technologies, and the business requirements. They need a reconciliation between the key roles of software developers, software engineers, and managers which have to collaborate and share a uniform approach when working within the software.
• Business risk. Unfortunately, most organizations are unable or willing to properly manage risks early in the project. Even today (2018), almost the majority of  development companies make proclamations of being agile when the daily reality is dramatically different: costs, activities, people, and risks are managed accordingly to the waterfall model. In such assumptions, risks are typically addressed at the end of the software development lifecycle, when the product is already legacy.
• Commercial components. Commercial components in the form of libraries, services, API, widgets or frameworks are a necessity for every large-scale system. If not properly managed, such high level of (commercial) “componentization” poses some risks because they can generate legacy software very prematurely. Technologies evolves very quickly in the software world. The commercial time required to release new systems is always shorter in a competitive market. Resources required to build systems at the state of the art lack, especially from the side of well-trained people. As a result, the quality of commercial components is not always as high as we expect from tested, reusable, and documented off-the shelf components. Many of such small software systems are then subjected to corrective or evolutionary maintenance. New patches are introduced and new versions of them are continuously released. If a software product is already well into the test phase, the configuration management boards of many organizations are unlikely to accept the introduction of new versions of commercial components because the risk of introducing instabilities in the final system is too high. Consequently, system will contain obsolete, legacy code and becomes legacy by itself.
• Business objectives and the evolution of software. Many software systems are developed as part of larger products (e.g. airplanes, cars, industrial plants, etc.). The organizations that build such systems are typically service providers or commercial manufacturers, not specifically software houses. In these cases, the prominent organizational culture is not aligned with the values of a software house that should consider the software as a primary knowledge asset. In industrial and commercial environments, the product is the real, perceived (and sold) value. The software (integrated in the product and often even not visible to the users) is merely considered a cost. It is not a surprise that in such contexts the organization’s main goal is to build the product in order to make money, not to craft software. Everything that allow them to reduce the costs maximizing the revenues is systematically chased. So the first effect of cost reduction in software development is reduction of the internal quality of a system, and again, legacy components are proliferated very quickly and very broadly in the system. Even when the first symptoms of software erosion start to emerge, organizations prefer to invest resources on the release of new functionalities rather than to address the necessary refactoring required to keep the software complexity under control. In conclusion, it is not unlikely that such organizations simply lacks the necessary culture needed to develop solid, maintainable end extensible software systems. It is only when a catastrophic situation happens that maintenance, extensibility and testability appears as a issue. This is very critical because, according to Lehman’s Second Law of software systems evolution, “as a large program is continuously changed, its complexity, which reflects a deteriorating structure, increases systematically unless work is done to maintain or reduce it” [Lehman and Belady, 1985]. More recent studies have confirmed this prediction: the relative cost for maintaining and evolving software systems has been steadily increasing and now represents more than 90 percent of the total cost of ownership [Erlikh, 2000]. This confirm that legacy systems are all around us. Everywhere. Everyday.

All the previous factors, combined together, make the emergence of legacy systems as a normal consequence that threatens the governance of almost every software infrastructure that we exploit today, from the banking, financial, and insurance sectors to the healthcare, telecom, transport, military and information technology fields. If we, as a computer society, want to preserve the quality of service and in many cases also the service availability of such systems, we need to promptly address the impact of both technical debt and the before-mentioned factors. We need more investments in the modernization of software infrastructures, starting with a better cultural alignment between the organizational goals, the technical competencies and the business value intrinsic in the software. Otherwise, we could experiment either the unreliability or the unavailability of many services that we consider indispensable in our lives.

 

[Erlikh, 2000] Erlikh, L. Leveraging Legacy Systems Dollars for E-Business. IT Pro, May-June, 17-23. IEEE. 2000

[Lehman and Belady, 1985] Lehman, and Belady, L. Program Evolution: Processes of Software Change. Academic Press. 1985

[Seacord et al., 2003] Seacord, R.C.; Plakosh, D. and Lewis, G.A. Modernizing Legacy Systems. Software Technologies, Engineering Processes, and Business Practices. SEI Series in Software Engineering. Software Engineering Institute. 2003