Sacrificial wear in software

There is a concept in mechanical engineering called sacrificial wear. When two mechanical parts come into contact, they will inevitably eventually damage each other beyond use and have to be replaced. This is life for mechanical engineers.

However, part of the problem of replacing something is that you need to spend time taking it apart and fixing it; and worrying about where all the little bits of ground up metal have gone. Also, the problem is that both parts get worn; and might, in fact, wear out at slightly different rates so you might have twice as many failures. So if we design something in such a way that one of the two parts is made of softer metal you know it will wear faster. So, you can 1) know that it will always be the soft part that wears, the hard component will “never” wear; 2) you can optimise your design so that the soft part is easy and cheap to replace; all the clever stuff is in the bit that never wears. One example is Shimano SPD pedals. The clip on the pedal is clever and made of hard metal; the flange on the shoe is softer, simple to replace and very cheap, being just a square of steel with a hole in the middle.

This is one of the reasons why mechanical engineering is harder than software. After all you don’t need to worry about that for loop wearing out. Or do you? In fact, I think that there is some use in this kind of thinking. We don’t have code that rusts; but it does, when subjected to enough corroding changes, have faults that we think of as “structural”. We don’t have class that needs to have a big enough hole in it to get a spanner inside to change the grommets; but we do need to make extension points for our classes so that they can be extended.

Config files are the simple extreme of sacrificial wear; we “know” we can change config without damaging the application. The config file is part of the software and there should be no reason to treat it differently except that it has been designed to absorb a certain type of common change. IoC config files challenge the limits of the config file and behaviour that is “normally” contained imperative code creeps into a file that we call config.

Another type of sacrificial wear is the pattern I call “crap shield”; it’s somewhat like facade, but it’s purpose is more explicitly to hide any and everything that I don’t like. It can contain many facades; all the web references; all the links to dying databases; all the millions of project references that are needed to support a big 15 year old system. It keeps the code clean in my project though; when there is a problem with the “everything else” I know where to look.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s