Wherever software is used, there is a risk that old systems will mutate into legacy systems. This means that they can no longer be further developed or maintained within reasonable costs and without foreseeable technical risk. So how can you prevent a system or legacy system from becoming a legacy system? Read
the following article to learn how to identify legacy systems in time, how to remove them and ultimately how to avoid them.
Table of contents
An essential quality criterion for software is long-term maintainability and expandability. By focusing on this criterion, it can be ensured that future extensions can be accurately classified in terms of costs, implementation time, cost-effectiveness and risk. Figure 1 uses the green line to show an optimal cost development in relation to the age of the software. An initial increase in costs is associated with investments in quality, which stabilize costs in the medium term and keep the software alive.
In contrast, the red line shows a possible development for a system where quality criteria are neglected. Each red dot shows a decision in development where a compromise was made between quality and cost or possibly implementation time. This creates something known as “technical debt“ in the software. This technical debt leads to an increase in the complexity of future maintenance and enhancements, and therefore an increase in the cost of change, as well as the associated risk. From experience, technical debt quickly leads to parts of a system or the system as a whole becoming impossible to maintain or extend.
The evolution of a system towards a legacy system is generally easy to measure. Among other things, the following signs can be observed here:
Figure 1: Cost of change
Technical debt will always arise in the course of software development. This is unavoidable. However, the processes in software development can be prioritized in such a way that technical debt can be reduced. A common mindset in the project team is necessary for this. A constant monitoring of the technical debts and the authorization of the developers to be able/allowed to remove these again are inevitable for this. Methods that are used here include code reviews, coding guidelines, pair programming, refactoring and test-driven development. Figure 2 shows the constant correction of technical debt through small adjustments.
Figure 2: Constant quality management
Depending on how far along the software product is on its journey towards the “end of life“, minor adjustments may no longer have any effect and major refactorings or reengineering may become necessary. In this case, it is helpful to bring reengineering specialists into the project team to gradually perform a consistent reengineering of the existing legacy systems (ris.w4.at/en/technical-article-software-reengineering). Figure 3 shows the late identification of technical debt. Here, countermeasures must be taken with significantly more effort and time in order to bring the system back onto the right path.
Figure 3: Reengineering, major refactoring
In addition to observing technical debt, the question arises as to how technical debt can be avoided. To do this, it is necessary to analyze how technical debt comes about. What are the causes and what can be done to mitigate these causes?
As stated in the previous section, developers are the ones responsible for the technical quality of a software product. Technical guilt is not integrated therefore deliberately into a system, but promoted by external factors. If one regards the temporal course of a software development, then the following connection can be determined: The blue line shows the linear project execution, i.e. the fulfillment of the planned project scope up to the delivery date at V1.0. The ideal line in reality should correspond to the green line. There are continuous adjustments in the implementation, which keeps the product development “on track“ and thus ensures that a valuable, executable product is available on the planned date.
Figure 5 shows a picture which, however, is usually found in reality. A deviation from the plan is noticed. There can be various reasons for this. Possibly an initial estimate was not accurate, the team has lost efficiency, there are external influences such as sick leave, the complexity of the software has changed, the project scope has changed, etc.. The reasons for this can be many and varied. However, at this point it becomes interesting to see what options a project team has. The following primary decisions can be made considering the circumstances.
Figure 4: Development course
Figure 5: Reality
The postponement of the completion date is done only if the people responsible for the product have the possibility to do so. Behind a postponement of the completion date are usually other people or systems that are dependent on it and more or less insist on the originally planned date. In addition, there is the disadvantage that not only a go-live and thus the (possibly economic) benefit is postponed in time, but also the project team has to be financed for a longer period of time. This leads to additional costs and later revenues. A direct, negative impact on the ROI is the consequence.
Figure 6: Move the release date
The least resistance can be expected if the developers‘ working speed can be optimized to meet the completion date and the development costs. In fact, this is an option, although we need to distinguish between two different scenarios.
Option 2a: There are influencing factors, which disturb the team in the efficiency, which can be actually repaired. These measures work and are also those that take place during continuous process control and improvement. The scenario in Figure 4 assumes precisely this. The prerequisite for these measures, however, is that the deviations are not detected too late and are not too large. In Figure 7, it may already be too late for such a measure.
Option 2b: There are disruptive influencing factors, but these are not dealt with or it is too late for appropriate measures. In this case an increase of the development speed is reached only by the structure of pressure on the developers. Pressure usually leads to the fact that in the methods one saves, which do not have an obvious direct influence on the product range of a software. These are those, which are necessary for the preservation of the quality and thus it comes successively to a structure of technical debt. Since there is also a lack of time and capital for the reduction of the technical debts, this build-up progresses with appropriate speed if necessary.
Figure 7: Increasing the speed of development
The third option is to adapt the content of the software product. However, the product owner must have the appropriate authority to do this, and intensive negotiations between the product owner and the stakeholders may be required. Adaptations of this kind are facilitated by various measures:
In fact, such an adjustment in the project scope is possible at any time in the implementation. Detected in time, the changes are marginal; detected late, the changes are correspondingly more extensive. The following applies here: Provided that the product already contains the most valuable functions, a productive implementation with a reduced scope of functions should not be an obstacle. With appropriately well-trained and experienced product managers, this risk can be significantly minimized or even avoided.
Figure 8: Adjustment of the project scope
As is so often the case, no general statement can be made here. Possibly one of the options makes sense on its own or a corresponding combination of options 1, 2a and 3 leads to a corresponding correction of the price. Only option 2b should be avoided, since exactly this ultimately develops a system in the direction of “End of Life“.
Measures that ultimately prevent a legacy system are
Finally, an important influencing factor should be mentioned, which can limit options 1 – 3 accordingly: The contract. It is understandable that clients want to have contractual security with regard to what scope will be delivered in what time frame at what cost.
For this reason, contracts are often concluded with the contractors in which all three factors are fixed. However, this leaves the person responsible for the product with no room for maneuver:
Thus, from a contractual point of view, usually only option 2b remains, namely increasing the pressure on the developers and the associated minimization of the quality of the product.
Instead, it is recommended that release dates and costs be fixed (e.g., by stabilizing the team) and that flexibility be created in the requirements for a product. Through the leadership of a product manager, clients can control the required functional scope of a software product up to the release date and thereby obtain transparent cost control. In addition, the product can be adapted to market needs during implementation and thus positioned in a target group-oriented manner.
Head of Unit Domain-specific Applications, Head of Coaches
