Jonathan Boccara wrote a great article last month about the importance of a good attitude when we have to deal with legacy code. But what about those times when it’s not just the legacy code but the whole system that needs to be upgraded? This is where you have an opportunity to make a case for upgrading legacy systems.
It could be that you have a chance to give a formal presentation, or it might be a moment when someone important asks what you think about the system. It is very important to know how to make a case in favor of upgrading or replacing legacy systems, so that you will be ready when your opportunity comes.
I grew up hearing my dad repeat the old saying, “If it ain’t broke, don’t fix it.” That always bothered me. Growing up I loved building things and trying to find ways to improve upon the status quo. What you have may work, but what if there were a way to make it work better?
“Better,” here, could mean something that works faster, uses less resources, is simpler to operate, or gets more work done before a deadline. It could mean something with less downtime and less maintenance costs.
One of the misconceptions that drives the “if it ain’t broke, don’t fix it” belief is that it is easier to leave things the way they are than it is to risk the time and energy required to improve something that already functions. This is true in the short term but has many times proven false in the big-picture view. When one looks at the compounded savings over a longer time period—say two to four years—the initial investment in system upgrade usually seems small in comparison.
I believe that we should always strive for improvement. The horse and cart were by no means broken; however this did not stop the invention and progression of the combustion engine. Unfortunately in the area of IT, this old saying has been applied and enforced with such passion that we now have an abundance of legacy systems, which are syphoning our resources and decreasing quality and efficiency.
In 2014, Windows XP turned 12 years old. That's an eternity in software terms. At that time, however, over 95 percent of ATMs were still running Windows XP. Because Microsoft had decided to stop supporting and patching XP, this scenario became a very large and very expensive problem for banks to fix.
Software is not the only IT asset to face down legacy problems, though. Legacy hardware brings its own set of issues. Because of the close relation and interdependence between IT and software development, this disturbing trend impacts programmers greatly.
Maintainability
In general, the older a legacy system becomes, the more difficult and resource-consuming it becomes to maintain. A mechanic friend of mine once advised me that while it seemed more affordable to keep my older car, in reality it would “nickel and dime you to death.”
What he meant was that many small problems and repairs were bound to occur with a car over 30 years old. These repairs might each be small relative to buying a new car, but as they compounded over time, it would cost much more in the long run.
This idea is important to remember when considering whether or not to upgrade your legacy systems, both software and hardware. When the software company discontinues application support and updates, it then becomes the in-house IT department’s job to maintain the product.
Unless you have the source code and a team of developers dedicated to maintaining that product, you cannot adequately discover and patch vulnerabilities and issues. Once hardware manufacturers stop producing the parts for your system, you run the risk of paying very high prices for used parts due to their scarcity. All of these factors can create a legacy nightmare that can cripple a business.
Several years ago, a customer brought a computer into the shop that I was working at to be repaired. This was the definition of legacy, as it was running Windows 95. She insisted it had to be fixed because it was the only computer that could run the embroidery equipment that her business depended upon.
Her entire business was resting on the continued functionality of a Windows 95 operating system that was running on original hardware. I fixed it to the best of my ability and highly recommend that she look into upgrading her equipment or finding a way to run it on newer software. The longer you indulge legacy hardware, the higher the chances of suffering a critical failure.
Scalability
Scalability is quite the buzzword these days in the IT and business world. It refers to the ability of hardware and software to dynamically adjust to meet changing levels of demand. Improvements in virtual computing and bandwidth speeds have created an unprecedented ability to adjust your resources as needed to maintain full efficiency.
Legacy systems can greatly hinder a company's ability to scale their resources. Using legacy methods or practices can hinder scalability because many are outdated procedures that do not take advantage of current technology.
In the early days of computers, database management systems (DBMS) did not exist, so all information was stored in text files instead. As storage and processing power grew, DBMS were created to better store and retrieve information.
I worked for an IT department that managed about 200 retail stores. This department used multiple excel files to store different information about each store. This system had worked fine in the past when they had under 50 stores; however, it had failed to scale properly. Information was mismatched and outdated across all files.
As a result of an outdated system, significant resources were lost trying to maintain this legacy methodology, which had worked in the past but was no longer appropriate. This loss of resources was a great hindrance to the IT department's ability to scale along with the rest of the business.
Legacy hardware can also inhibit scaling because of its inability to handle greater volumes. It’s also important to remember that the ability to scale down is just as important as the ability to scale up. Spending large amounts of money to add more pieces to a legacy system to keep up with demand can hurt you if the demand decreases but the hardware has already been purchased.
Flexibility
Flexibility is a key factor when considering any system. With the rapid output of new devices and technologies, each with the potential to dramatically impact the current business world, the ability to modify a system and expand or change its purpose is critically important. Using a versatile framework ensures that you won’t need to change or add new systems as your needs develop and change.
Many legacy systems suffer from inflexibility. Because of hardware limitations, many older systems were highly specialized for specific tasks in order to achieve more efficiency. The more specialized a system is, the more difficult it is to modify it, even in small ways. The task of adding or changing a feature becomes much more daunting in the context of a legacy system than in a newer system that was always intended to be more generalized and flexible.
Compatibility
Compatibility can be one of the most obvious issues created by maintaining legacy hardware and software. An inability to handle modern protocols and data can make legacy systems cost more time and resources than using a newer system.
When I was working freelance in IT, one of my customers started another business. To save money they purchased a large, free-standing multifunction printer, an early Windows XP-era product. I can confidently say that any money they saved by buying such an old machine was more than lost through the costs of making it work.
It took complex workarounds to get basic functionality on her network, and even small changes (like adding a new computer to the office) required an onsite visit to make it function. These problems were all caused because the system did not match up with today's common hardware and software protocols and configurations.
Cost
Many employers will cite cost as a reason not to upgrade systems. They believe that it would be much more expensive to replace and upgrade legacy systems than it would be to simply continue doing things the way they always have.
Because of this misconception, it is important to differentiate between capital cost and overhead costs. Legacy systems inherently have zero capital costs because there isn’t anything to buy. Upgrading or replacing these systems usually involves a high overhead costs by comparison.
However, you must also consider the long-term impact of the overhead costs. Many newer systems have much lower overhead costs after the initial investment, whereas legacy systems continuously use up resources, compounding overhead costs, as we’ve discussed throughout this post.
According to the FCW, in 2011 the U.S. government spent over 70 percent of its IT budget on maintaining current systems, while only 25 percent went toward developing new systems. That is not even taking into consideration the cost incurred by lost productivity when these systems go down for maintenance or simply run slowly due to outdated hardware.
A private business can even suffer from the loss of customers and sales when the legacy systems negatively impact the end user experience. When the monetary value of all of these resources is considered, the overhead costs of continuing to use legacy systems becomes clear. It is the combination of capital and overhead costs of the current and potential systems that must be compared to get an accurate view of what will be the most beneficial for a company.
Knowing When to Act
Not all legacy systems are bad, and I am not suggesting that you storm into your boss’ office tomorrow demanding to upgrade everything. However, when these systems become resource parasites for your company, it is critical for you to know how to properly assess the situation and take the best course of action.
As software developers, part of our job is to find the most efficient method of achieving the desired state. Sometimes that means getting involved in areas outside of our own, such as business or IT.
We need to take on a sense of responsibility for the company as a whole rather than just the lines of code we write. I hope that if you ever have to make the case against legacy systems then this article can serve as a starting point, helping you to better your company. If we believe that a change will be beneficial, then we shouldn’t be afraid to propose and advocate that idea.
