Antipattern: Never change a running system 🚧

Author(s): Andreas

“Never change a running system” - probably everybody working in IT has heard this sentence. This can be an anti-pattern when there is the “system” and nobody wants to touch it in fear of breaking something.

The system is either very critical or complex so that this fear of breaking it when changing it comes to exist. Often people are discouraged from even trying to change the system, which leads to monopoly of heads or even no one beeing able to change the system anymore. Also often people start working around the system and wrapping additional layers around it to add functionality or even fix bugs. This then leads to an even more fragile and complex system.

Nobody wants to work on such a system, it will be hard to find developers and hard to motivate them. So the problem will increase even further. When software is no longer maintained and updated regularly, libraries and frameworks will soon be outdated, and they will no longer play nicely with the surrounding systems. Other system elements will start to build anticorruption layers around it. Often this results in reimplementing/reverse engineering the system. This comes with high costs and even higher risks due to the lack of information.

What are some examples?

🚧 missing examples in case studies 🚧

Why does this happen?

How can we avoid getting into the situation in the first place?

What are suggestions to get out of the situation if we ended up in it?

Often the preferred way will be a re-implementation of the system. But this is not the ideal solution due to the immense costs and risks. There might be reasons for such a drastic step, for example if the environment is outdated like COBOL code on a host environment, but most of the time it is better to keep the system alive and kicking. The better way is simply to name but hard to do. Start reducing the technical debt. For that the following steps are normally useful: