Software Needs Oil Changes

I had a conversation with a shop owner a while back that's stuck with me. His invoicing software had been running the same way for six years. No downtime, no complaints, nothing he'd ever had a reason to touch. When I mentioned it might be worth a checkup, he looked at me like I'd suggested he get his car serviced while it was running fine. "It works," he said. "Why would I pay somebody to touch something that works?"

The honest answer isn't about his software today. It's about the ground his software is sitting on — and that ground moves whether or not he ever changes a line of code.

The ground moves even when you don't

Software isn't just the logic somebody wrote. It's built out of a stack of other people's work underneath that logic — the programming language, the libraries that talk to the database, the framework that handles requests coming in from a browser. Every one of those pieces has its own release schedule, its own bug list, its own security fixes. None of them wait for you to be ready.

A lot of that movement is driven by security specifically. Something considered safe a few years ago gets found to be exploitable this year. The people who maintain that piece patch it — but only if you're running a version recent enough to receive the patch. Software that hasn't been touched in six years is very likely sitting several versions behind on things the owner has never heard of, each one a small crack that's gotten a little wider every year nobody looked.

None of that shows up as a bug. The invoicing software still opens every morning. Invoices still print. Working and finished were never the same thing. Working tells you the logic still runs. It tells you nothing about what's underneath it.

The oil change doesn't wait for the engine to fail

An oil change is the clearest version of this, because everybody already understands it. You don't wait for the engine to seize before you change the oil. You do it on a schedule, while the car is running perfectly, because that's the only way it keeps running perfectly. Skip it once and nothing happens. Skip it for ten years and you're not buying oil...you're buying a new engine.

Software has the same shape, plus a wrinkle a car doesn't have. A car's parts don't shift positions while it's parked in the driveway. Software's do. The languages and libraries and platforms it depends on keep moving on their own timeline, whether the app is a weekend project or the thing that runs a whole shop. I let a personal project's dependencies drift for about two years once, told myself it was fine because nothing had broken, and then spent a weekend I didn't want to spend catching it back up all at once. Nothing had broken. That was the problem.

What it actually costs you

One of the case studies I've written up is a system built in 2014 for one of the largest school districts in the country — a funding-allocation engine that's still producing correct numbers today, more than ten years later. That's a real accomplishment, and it says something true about how the thing was built. "Still running correctly" and "maintenance-free" are two different claims, though. A system built to last still needs the same scheduled attention a well-built car does. Skip that attention long enough and the bill still arrives — just later, and as an outage or a breach instead of a service appointment.

Ongoing maintenance is a line item you can plan for and budget against. Nobody checking the dependencies for five years, and something finally breaking in production or getting exploited, is a different kind of expense entirely — closer to a fire than a service appointment, and fires always cost more than the maintenance that would have prevented them.

If you've got software that's been running quietly for a few years and nobody's checked what it's built on lately, that's worth a look before it becomes urgent. That's the actual work behind the legacy rescue process — not "your software is broken," but "let's find out what's changed underneath it before it finds you." Worth a conversation either way.