DEV Community

Catherine Galkina for Typeable

Posted on • Originally published at typeable.io

Legacy: alarming symptoms and problems

Author: Victoriia Zaripova

Introduction

The purpose of this post is to give non-IT specialists a basic insight into the hazards of obsolete computer systems and code, and the way they may harm the business.

You might have heard the word "legacy" – usually with a negative connotation – from the technical staff. This term is used to denote the methods, technologies, and computer systems or application software that are declared to be obsolete due to some reason. However, does this legacy always have negative implications for the business, is it mandatory to get rid of it and how can you understand that it really creates problems?

As a rule, the developers, analysts, testers, and support staff are those who face the legacy issues most often, which is evidenced by the broad experience of our own team. For end-users, these issues usually remain under the bonnet, and for CEOs they are concealed behind report figures without showing any logic behind them.

Having legacy code is like driving a fancy-looking car with dieing engine

Basically, the situation, on the whole, reminds of the permanent tuning of outside appearance and interior in a car where the engine is at its last gasp but the passengers suspect nothing. Sooner or later, this automotive marvel is bound to die somewhere between point A and point B, but until that time the car will make a positive impression, especially if the passenger compartment is extremely comfortable and the suspension – or, speaking straight out, the frontline – allows driving over potholes almost smoothly.

However, there is also no point in replacing your tried and tested tractor with a trendy smart right on the spot. Everything depends on the objectives and current state of the issue

How can you understand that legacy is a hindrance?

Here is the list of alarming symptoms and issues you can notice even without being a professional:

Lack of well-defined and clear documentation for the supported business processes

Perhaps, now the documentation seems to be of no importance since each of your employees is a real pro who can explain the entire business process from A to Z at any moment and knows the information system they are using inside out. However, the real-life experience usually shows that this is far from being the case. Moreover, even the terms used by the personnel in different departments differ significantly. The most basic example is the attempt to build the business process for supply agreements approval. Lawyers treat the term “agreement” quite differently from accountants, and both departments focus on entirely different stages of the agreement approval.

Well-organised BPM is important

Today, businesses are more willing to recognize the value of transparent and well-organized business processes and you’ll have little difficulty in finding a post on the advantages of this approach. Here is an example: Benefits of BPM | 11 Massive Advantages of Business Process Management. Besides, this article is also notable for the studies it’s based on, in particular, the study of 2020 stating that the outbreak of COVID made businesses invest more in the business process automation and altered their assessment of how important it is to change the obsolete processes.

Rigidity in improvements

Due to some reasons you are not able to integrate easily and quickly with the leading services, timely scale up or flexibly modify the software and, consequently, always miss the boat of market opportunities.

Just believe, this is not a chain of tragic accidents, but a disturbing symptom.

This symptom is especially clearly seen in governmental institutions where rigidity is embedded in the work format, and where all changes require long-term approval. For instance, excess expenses of the US government for the IT infrastructure in 2019 (over 70 billion dollars) triggered the internal investigation showing that obsolete software is the key issue.

Nevertheless, commercial companies whose way of operation implies flexibility and openness to new technologies also suffer from the legacy. Airline companies, banks, insurance companies, and retailers sooner or later turn out to be unable to overcome the rigidity of obsolete software. As a result, their operation becomes unstable, they are not able to bring new products and services to market or even stably support the existing ones. For example, in August 2016 Delta Air Lines faced an unexpected failure of the booking, check-in and boarding systems which always seemed to be reliable, which resulted in an hours-long downtime and cancellation of more than 2000 flights. This and other cases are described in the post "Legacy systems are problems for boardrooms not computer geeks", Financial Times, Jan. 31, 2017.

Over 2000 flights have once been cancelled bacuase of obsolete software

Low spirits in the IT team and loss of users’ loyalty

One would think that the legacy cannot affect the team morale.

There is no secret, as any modification of legacy systems resembles a patch on the A-bomb – most probably it won’t go off but you wouldn’t like to touch it again if you can help it. Specialists in obsolete languages and technologies don’t come cheap – one has only to think about the Y2K problem. Novices, on the other hand, try to patch the old environment with something new, so with time, all this becomes a monstrous zoo of technologies where not every specialist would dare to plunge. As the result, the users complain more and more about the problems and the product development is hindered.

Moreover, the personnel are more likely to leave as they’ll be demotivated and not willing to dig through the problems of obsolete monstrous code with documentation missing or passed over as verbal folklore.

Dealing with legacy code is discouraging for the developers

Of course, no one is indispensable, but you should remember that selection and adaptation of a new staff member come at a price and the more complex and intricate the project is, the more time it will take the new employee to become up to speed (while being paid for work with the old code!). Meanwhile, the rest of the team will have to solve business-critical problems.

And now imagine that dramatic market changes (and they’ve always been dramatic recently) require an immediate response. It’s not necessary to imagine for yourself, you can just read what situation the businesses are facing today: The coronavirus (COVID-19): business impact.

Standard solutions

Thus, we’ve found out that legacy is not just a problem for the IT department but also a potential threat to the company stability and growth. Let’s consider standard solutions for this situation:

  1. Ignore – this path can be costly if you already see the problems listed above but it can be optimal in some cases. In the long run, if the business pathway is unchangeable, it’s better to rely on the trusted comrade-in-arms with whom you went through fire and water;
  2. Replace it with completely new software – sometimes this path is the only possible solution because the legacy, like a disease, can infect the environment very quickly.
  3. Replace gradually/component-wise – this way is usually the revolution from below, when the IT department systematically performs refactoring of the home system, but it usually requires almost boundless tenacity and consistency;
  4. Reengineering of business processes and the software – this path is perhaps the most radical, practical, and effective but it’s labour-intensive and needs the deliberate commitment of the management.

Conclusion

As you can see, legacy can do harm to the business, not only to the programmers’ nerves. You can deal with the legacy in different ways, and different ways will work for specific cases.
In our next post, we’ll describe in more detail when and what way should be selected and will also tell how technical tools can help you to work with the legacy.

Discussion (0)