Software rusts.
This surprises people, especially non-technical people who assume that because it doesn’t “wear out” from use it’s akin to a perpetual motion machine. But try to patch a bug, update a dependency or even just install an old project and you’ll see what I mean immediately.
First you’re reinstalling old language dependencies, then debugging weird hardware errors. By the time you resort to dockerizing the whole project feels less like a pristine mammoth frozen in ice and more like the La Brea tar pits. And after it’s running the first tiny update drops you straight into dependency hell, where years of incompatible library requirements seize up against one another like a rusty crankshaft.
How does this happen, and how can we explain it to clients?
For analogy let’s imagine a grandfather clock, a rotary phone, and a car are locked away for half a century or so and then pulled out of storage.
Grandfather Clock: Stable but Static
The grandfather clock is in good shape, complex, yet static. All it needs is inside its case. Wind it up and it will tick at a second per second. Static programs are like this. Given a stable environment in which to run they’ll work as long as you like.
Rotary Phone: The World Moves On
Similarly, old software programs may run perfectly well internally according to their original specs, but no longer integrate with the changing outside world. Dependencies break, frameworks shift, and browser standards evolve. Flash programs and java applets were cool once, but certainly won’t work on modern devices. In a recent example, google emailed me saying all my project’s google drive integrations would stop working unless I reset and reconfigured them. My website hadn’t changed, but Google had.
Make sure your clients understand the likely rate of change of the ecosystem around their software. If they don’t factor in changing standards and external dependencies, they might be buying a rotary phone and expecting it to work with 5G.
Car: The Cost of Complexity.
Finally let’s see how the car fared. It diverges from external standards like the rotary phone, as our antique lacks modern safety standards of seatbelts, airbags, anti-lock brakes and unleaded gasoline. The internal breakdown is even worse. The tires dry-rotted, the gas rusted through the fuel lines, the oil has turned sludge, and the transmission and engine are shot. It’s probably cheaper to replace than repair.
Complex, multifaceted software also degrades; the more complex, the faster. Each dependency and API is one more potential conflict or point of failure. Internally requirements change, functions are repurposed, and vestigial code moulders in the dark.
Now the problem is not “cars are complex” or that big codebases are bad and small static ones good. A grandfather clock is not “better” than a car because it can sit in a garage for longer! To work, most software needs to be exposed to a complex and changing world of security updates, new requirements and operating systems just as a car is exposed to the elements. The problem is that it was a intricate and dynamic machine that was abandoned for too long.
The Used Key Is Always Bright.
The parallel for code then is obvious. Don’t leave your codebase languishing for years! Keep it running, do regular maintenance, revisit often and don’t let a minor update lag snowball into a major one. Unless you have a very simple use case, you’re not going to be able to do a one-time vacuum seal and have your codebase run indefinitely. Instead you need to the simple chores of updates and patches to keep it a well-oiled and polished machine.
The used key is always bright.
Benjamin Franklin
Embrace the fact that software changes over time. Document and automate to stay on top of churn. Pay off technical debt before a small patch of rust grows into a big one.
Remember that most of the lifetime cost of software lies in maintaining it, not creating it, so anything you do to lessen those costs will pay off. Not only will updates be easier but your software will be better tuned to your needs. Like a car, the best way to keep a codebase in great condition is to keep it well-tuned and running.
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
