Does software have breakaway parts?

Full article

Have you ever driven away with a gas pump nozzle still in your car? (Hopefully not!) Did you know that, by design, you won't drag the entire pump down the road? Check out the top of the fuel hose next time you're filling up, where it almost connects to the pump. There's a metal coupler near the top that serves as a breakaway - it breaks apart, salvaging the rest of the pump.

I started thinking about all this when my windshield wipers needed repairing awhile back. They were iced up, and I made the mistake of turning them on before I'd cleared it all, damaging the wiper transmission. It would've been nice if an engineer had introduced a breakaway part that, under unusually high stress (like being stuck by ice), snapped before the more expensive part - something easy to access and cheap to replace. sigh..

We encounter breakaway (sacrificial) parts frequently, though we're usually unaware of or just forget about them. The breakers in your electrical box trip before a heavy load causes a fire, and before that fuses served the same purpose. Fuses are still used in cars and various electronics, the element inside melting when there's too much current. A lot of hot water tanks have an anode rod in them that disintegrates over time due to electrical charges in the water, preventing the inside of the tank from being damaged.

Can we use this concept in our software?

Although software isn't physical, and the constraints aren't the same as hardware, breaks will inevitably happen to both, no matter how much caution is taken. It's a matter of recognizing and accepting that sometimes you can only control how much of a system fails, not whether it fails at all.


The closest we have is probably the try/catch block, or whatever similar device exists in other languages. We know some specific area is highly susceptible to issues, which might be out of our control (i.e. a network issue). So we add code that, like fuses and anode rods, remains out of sight until it's needed. It's sorta like insurance - spend a small amount on something "extra", aware you might never need it, but thankful when you do.

Caveat: Don't depend on try/catch blocks. Exceptions are exceptional. Just like thermostats, sensors, cooling fans, and other mitigating hardware is preferable to broken parts (even ones meant to break), leave try/catch logic as a last resort - extra code that takes the hit for the rest of the app when the worst happens.


Grant Winney

I write when I've got something to share - a personal project, a solution to a difficult problem, or just an idea. We learn by doing and sharing. We've all got something to contribute.

Comments / Reactions