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. 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.

There's a place the oil change analogy stops working. Any shop in town can service your car. It's a mass-produced machine with a manual, a published maintenance schedule, and thousands of mechanics who have seen a thousand just like it. The software your business runs on is a one-off. No manual, no service history, and usually one person who ever really understood it. Often that person has already moved on.

That last part is what I've spent my career on. The funding system I mentioned above, I built it and then maintained it for more than a decade. Two other organizations, in unrelated industries, the same story. Building software is the part plenty of people can do. Sticking around afterward is the part almost nobody does.

So if you've got something running quietly and nobody has looked at what it's built on in a while, there are really two questions. Where does it actually stand right now, and who is going to keep it there. The first one is what a system assessment answers, at a fixed price, and the written answer is yours to keep whether you do anything else with it or not. The second one is stewardship, and it's the part that keeps the bill from arriving as a fire.