support cannot be rewritten

Legacy (from the English legacy – legacy) is the reality of any programmer. We explain how software becomes legacy and why this is normal, as well as what are the advantages of working with legacy. You shouldn't always treat legacy as a curse, you should look at it as a natural stage of the software life cycle. My name is Alexey Ruzin, I have been in development for more than 20 years, I have worked with various projects (new and not so new), I taught Python at GeekBrains and Yandex Workshop. I know about Legacy first hand. For the last 10+ years, one of my projects has been a complex ERP system for working with clients, projects, documents and finances

“Legacy” is a word programmers use to scare each other (and managers). It means outdated software, which is usually difficult and/or unpleasant to work with due to the small “exhaust” in terms of the effort invested. In general, the word “legacy” can be used to describe any “code” that is difficult to maintain. And the more complex it is, the more “legacy” it is.

Today we’ll tell you where it comes from, how to keep it “within limits” and how it can be useful for novice specialists.

It doesn’t matter how well and cleanly the code is written, sooner or later it will become legacy.

What's wrong with Legacy?

The main disadvantages of “legacy” for business are:

low ratio of benefit to invested effort for change;
slow changes;
Difficulties in selecting a team to work on the code.

For example, here is an excellent article in which the CTO of LinguaLeo (a service and application for learning languages) talks about the problems that forced them to switch to new technologies: “During quarantine, the workload increased 5 times, but we were ready.” How Lingualeo moved to PostgreSQL with 23 million users

Reasons why “legacy” appears

The list of prerequisites is conditionally divided into two groups: those that do not depend on the team and those that can be influenced. The first includes the obsolescence of technologies, operating systems, programming languages, protocols, libraries, frameworks, and approaches to system design (for example, when new capabilities appear, say, multi-core processors). Obsolescence means that they are replaced by new technologies that allow achieving results faster or cheaper. The entire industry is gradually switching to them, and if you don’t keep up with it, the software product becomes legacy.

Another group may include low culture or poor organization of the development process. For example, unfixed requirements for a software product can and will lead to conflicts between users and developers (and even within the development team). As the software develops, it is necessary to make changes to the documentation. Failure to do so will lead to the same problems. Users will be highly dependent on the expertise of developers. And if the latter quit, then recovering knowledge from the code, although it is possible, is usually a long and labor-intensive process, which leaves many questions “why did they do this?” or “why is this?”

Incorrect architecture or poorly designed code provokes the writing of “crutches” (a bad solution, at the time of writing which, we know that there will or may be problems with it in the future, but which solves the problem “here and now”). A separate article or even a book could be devoted to a discussion of architecture and design, but in short, a violation of generally accepted software writing practices, in particular SOLIDwill lead to problems.
Inappropriate technologies have been selected (DBMS, frameworks, libraries, or third-party services); scaling features are not taken into account.
Poorly written code: inexpressive names of modules, classes and variables, functions that are too long (unnecessary), high cyclomatic complexitycode duplication.
The lack of tests (preferably automated, but at least manual) leads to errors that cannot be quickly detected.
Poorly organized project: no version control system; lack of a problem book (a system for recording requests for changes to the system); there is no connection between commits and tasks (requirements);
The lack of people who have the skill to maintain the product code also makes the code more “legacy”.

The main reasons for the emergence of legacy: obsolescence of technologies, poor technical solutions/practices; lack of requirements/documentation; there are no people familiar with the project.

Legacy with “positive feedback”

An important property of “legacy” is its growth. If you do not make efforts to minimize, then with each change (and even without them), the degree of “legacy” will increase. As in the second law of thermodynamics, the entropy of a closed system cannot decrease. Therefore, we need to methodically “bail out the water from our leaky boat.”

Why are legacy cars reluctant to be replaced?

Any software should bring IT companies directly or indirectly income (or reduce costs). The existence of a legacy business in itself is of little concern as long as the efforts invested pay off. In most cases, slow development of a large system is more profitable than moving to a new system (where there are necessary changes or where improvements are carried out faster).