In German, we like to make up our own English words and expressions. For example, German IT-experts have invented the saying: ”Never change a running system”. What they mean by that is: ”If it ain’t broken, don’t fix it”. But is that really true? I don’t think so.
If it ain’t broke, don’t fix it
Why? Because just like cars, IT systems need regular service and maintenance in order to run smoothly over a long period of time. In my article ”Your Hardware will Fail – Just not the Way You Expect”, I described findings from Google researchers about hardware failures. One of the findings is that hardware components usually either fail right from the start or at the end of their life. This is describes best by the so called bathtub curve. As you can see in the figure the two curves “Infant Mortality Failure” (red) and “Wear Out Failures” (yellow) together form a bathtub curve.
[caption id=“attachment20702” align=“aligncenter” width=“640”][![Bathtub Curve](https://blog.codecentric.de/wp-content/blogs.dir/2/files/2013/12/Bathtub_curve.svg-1024x723.png)](http://en.wikipedia.org/wiki/File:Bathtub_curve.svg) Bathtub Curve - taken from Wikipedia http://en.wikipedia.org/wiki/File:Bathtub_curve.svg[/caption\]
Applied to IT systems this means: The older a system gets, the more likely its failure becomes. In addition to that you have to take into account that over time hardware spare parts might become scarce and vendor support for software might run out.
Always upgrade a system to keep it running
So instead of relying on your battle-proven system running for years without incident and change, you should regularly patch and update. Of course this bares risks and it is definitely not the most pleasant task. But you can mitigate the risks of updates by e.g., automatization with, e.g., Puppet, by running update test in virtualized environments, and by developing a patch management plan.
In the end, steady maintenance is much less of a hassle than standing next to your broke car on the highway not knowing if you will ever get it to work again.
First published at codecentric Blog.