Skip to content
Mail Symbol Mail Symbol

Software-Reengineering: When will the legacy system become a problem?

by DI (FH) Alexander Leutgeb

Business-critical software is not immune to a certain aging process. However, an equivalent replacement is often not that easily available. But when is the time to replace the legacy system with the help of software reengineering?

Table of contents

  • If it ain’t broke, don’t fix it
  • Missing or outdated documentation
  • Original developers have left the company
  • The knowledge base for the system is missing
  • Even the implementation of small changes is very complex
  • Constant need to fix bugs
  • Code Smells
  • The solution: Software Reengineering
  • Sources
  • Author
Entwicklung

If it ain’t broke, don’t fix it

A common saying is: “Never change a running system.” This sentence, which is presumably a modified form of the statement “Never change a winning team” by the British soccer player and coach Sir Alf Ramsey, is, however, hardly known in the English-speaking world. There, the statement “If it ain‘t broke, don‘t fix it.” is used instead. The statements are similar, but the second formulation does not seem quite as strict and dogmatic. In other words, one should only try to fix something if it is actually defective or damaged.

From a functional point of view, this would mean that a system is no longer capable of performing the task for which it was designed. For software, we can go a step further here. A software system is “in need of repair ” when it reaches a state that makes maintenance difficult or impossible. We have collected six signs for you that indicate that action is needed for your software system:

Missing or outdated documentation

If the documentation of a system is outdated or does not match the actual system in many parts, this is a clear sign of a legacy system on which many changes have already been made. Even worse is the lack of comprehensive documentation. Such a circumstance complicates the maintenance and further development of a system and makes it almost impossible to train new employees quickly.

Original developers have left the company

Usually, a lot of knowledge about a complex system is stored in the heads of a few employees. This leads to a situation where the continuity of the software is directly dependent on the original developers, especially if the documentation is not adequate. The continuous departure of these employees inevitably leads to a situation that makes further development of the system almost or fully impossible.

The knowledge base for the system is missing

A significant alarm signal is when there is hardly any understanding of the basic functioning of the software among the employees. In the worst case, no one in the company knows the original contexts and concepts. This makes it extremely difficult to find sustainable solutions if there is a problem. The solution often is quick “hacking” to solve the problem, but these accelerate the malicious circle even more.

Even the implementation of small changes is very complex

A “law” formulated by Lehman and Belady on the evolution of software [1] states that systems become increasingly complex until active work is done to reduce the complexity. If even the implementation of small changes or enhancements requires a great deal of effort, this is a clear sign that the system has already become too complex. If even small changes require a large amount of time, more difficult changes become almost impossible to implement.

Constant need to fix bugs

Large software projects will not ever be free of bugs, so, making regular “bug fixes” are necessary. However, if repeatedly fixing a bug leads to the appearance of a new bug, this is a sign that the architecture of the system may no longer meet current requirements. This represents the risk that small changes in the program will have unforeseen negative effects.

Code Smells

Code smells are parts of the source code, which are not faulty, but badly structured and implemented. For example, the duplication of source code, i.e., the use of the same lines of code in different parts of the program, has a very bad influence on the subsequent maintainability of the system.

The solution: Software Reengineering

If the “symptoms” are recognized in time, the decay of the software can be counteracted by using suitable methods in order to keep the quality of the system at a high level and to avoid possible failures. By Reengineering an existing system is restructured and above all also prepared for future development and extension.

While maintenance involves adapting software that is in a productive environment to changed environmental conditions and correcting detected errors, reengineering involves redesigning and implementing systems or parts of them from scratch.

RISC Software GmbH will gladly support you in the initial analysis as well as in the implementation of a reengineering of your software system.

Sources

[1] M. M. Lehman, “Programs, life cycles, and laws of software evolution,” in Proceedings of the IEEE, vol. 68, no. 9, pp. 1060-1076, Sept. 1980 vgl. https://ieeexplore.ieee.org/document/1456074

Contact









    Author

    DI (FH) Alexander Leutgeb

    Head of Unit Industrial Software Applications