Dear community, here are a few thoughts on software erosion, dirt, and the role of chaos. Although it may not seem so at first glance, all three terms are closely related and pose a major problem for us software developers. To better understand this, let’s use our own apartment (home) as a comparison.
Erosion
The term erosion describes a change in state. Something is lost because it is worn away. In rock erosion, for example, wind and weather gradually remove loose pieces that together form the rock. This process creates typical mountain formations, and they disappear the longer the erosion continues. It is therefore a fundamental process in our nature, which is both good and bad.
Software erosion is also a change in state. For me, the focus here is maintainability. It naturally decreases over the years. This doesn’t necessarily have to be due to the software itself, which has become more difficult to maintain due to fixes and extensions.
It can also be related to the introduction of new software development methods, a changed perspective on data handling, changes in the runtime environment, and many other factors.
As ABAP developers, we are very familiar with this. Applications from the 1990s and earlier are still the backbone of many business processes today. Since their initial introduction, the applications themselves and everything around them have changed.
To use our apartment as an example: the material our home is made of wears out over time. The tiles on the floor, the plaster on the walls, the water pipes in the walls, and all other components are subject to wear and tear. We can’t prevent this because it’s a natural process. We can only learn to cope with it and adapt to it.
Dirt
Dirt usually occurs naturally. Through erosion, but also due to many other factors. Let’s take our home as an example: its use causes dirt to build up. Simply airing out the house brings fresh air, which unfortunately also contains dust. When we cook a meal, the pleasant smell of fresh food doesn’t just spread throughout the house. The examples are endless.
In software development, dirt takes on its own unique forms. I’m thinking of development objects that are no longer used, commented and therefore dead source code, comments that are no longer relevant, outdated data, and much more. Ultimately, dirt is somehow also the result of erosion.
Overall, however, this is a natural process that we can hardly stop or avoid altogether. We have to learn to deal with it.
Chaos
Chaos is the last factor we want to look at. Chaos is a state and means that everything is in disarray. In such a state, pretty much everything is of equal value and of little value. It’s difficult to carry out a targeted action with a predetermined result. Everything is determined by chance.
Using our apartment as an example: if our apartment is in chaos and we’re looking for something, we’ll find it with luck or not. But chaos also has other unpleasant side effects. It prevents us from focusing our attention, so we don’t see the dirt, for example, or even get to it to clean it up. Worse still, the effects of erosion can only be recognized late, such as a burst water pipe.
In software development, chaos is the catalyst for dirt and erosion. Since you don’t have a clear picture of a development, every extension and every correction is a matter of luck. A bit like pouring something on a fire. If you’re unlucky, it was oil; if you’re lucky, it was water.
Take up the fight
I see software erosion as a natural process. You can slow it down, but you can’t stop it. I recently read the statement that you should actually rewrite your codebase every five years. There’s some truth to that, but as an ABAP developer with a 30-40 year-old codebase, there’s at most another layer of onion around it. Like new paint on old plaster.
For me, dirt is also unavoidable, but not to be tolerated. No matter where you see it, it means cleaning. We have countless tools to keep our homes clean. In software development, too. From methodologies like CleanABAP to tools like ABAP Cleaner. You just have to do it. But it’s part of our job as software developers, even if you don’t really feel like it.
Chaos can be combated, and contrary to many opinions, I also believe chaos is avoidable. In many places, there’s simply a lack of a suitable development culture. Most developers are neither well organized themselves nor well organized within their teams.
The result is individual services that are sometimes better and sometimes worse. At least to me, that’s what most ABAP development will look like in 2025. However, the model will gradually become unsustainable. Changing requirements for ABAP developments, their increased technological complexity, demographic change, and many other factors play a role.
Apartment and house owners usually set aside some money for planned or unexpected repairs. In Germany, this is calculated on a yearly or monthly basis using a formula that takes into account the age of the building and the size of the living space. Such a reserve is not mandatory, but it is helpful in an emergency.
For companies, I would be interested to know whether provisions for modernization have been set aside over the years of using some ABAP developments…
So far my thoughts
Michael