The value system

We would like to begin this section with a seemingly provocative thesis:

There is no software maintenance!

Maintenance is a proactive process. In production systems, parts are regularly replaced before they break. They are replaced because experience has shown that reliability would fall below a critical value if operation were to continue. So before the entire system comes to a standstill, the critical parts are replaced in good time. Every car owner knows that they need to have their oil changed regularly. Not because the oil is used up at that point, not even because the oil is already completely ineffective at that point. No, it is changed because the manufacturer's experience shows that the engine is protected by changing the oil in good time and therefore lasts longer.

None of this exists with software. Software is what it is. It usually contains errors. But even these errors are the way they are. Nothing can be done proactively to improve the state of the software.

Of course, there are proactive actions when operating the software. For example, it may be necessary to regularly check whether the log files still have enough free space on the hard disk, whether a database is overflowing or whether the memory is filling up. But the software itself cannot be maintained proactively. Every change or extension is made to eliminate an error or to implement new or changed requirements.

For changes to be possible, the software must have an internal structure that favors such changes. We refer to this as changeability. Software is usually operated over long periods of time. During this time, the framework conditions change and features need to be added. Ideally, the implementation of a feature costs a fixed amount that is independent of when the feature is realized.

In practice, however, the price of a feature increases the later it is implemented. In the beginning, features are inexpensive, but in the end it is no longer possible to add features because nobody can see through them. The software is thrown away and redeveloped. Until you reach this point, the costs increase exponentially. There are two common things about exponential growth: 1) Initially, you hardly notice that the costs are increasing. The increases are moderate. 2) By the time you realize that costs are rising, it's too late. The increase then suddenly progresses so quickly that it is no longer possible to counteract it.

The easier the software can be adapted to changing conditions, the greater its adaptability. But changeability cannot be achieved retrospectively. It must be taken into account from the outset. The software must be designed for it.

Here is an example: classes should have exactly one responsibility. If a class is responsible for more than one thing, it is more difficult to keep track of it. This hinders changes because they require an understanding of the source code that is to be changed. Furthermore, the coupling between the classes increases. Suddenly everything is connected to everything else. This can only be prevented if functional units have clearly defined responsibilities and you keep an eye on the coupling. If you have accumulated a number of classes in a software system, each of which is responsible for several things, it is difficult to eliminate this situation retrospectively. The coupling is so large that it is difficult to separate out individual functional units. If new features are to be implemented in this thicket, it is very time-consuming. If a start is not made in good time to clear out the thicket, the situation gets worse every time. At a certain point, it becomes almost impossible to add new features. The super-GAU of software development.

We believe that it doesn't have to come to this. If changeability is taken into account from the outset, software can continue to be developed over long periods of time. The costs per feature may increase slightly over time. But by no means exponentially!