Article summary
I’ve recently helped a few clients out with codebases in need of love and attention. The usual reason folks become aware that the software they’ve come to rely on needs attention is that one of the service providers they’ve been relying on has been sending them increasingly urgent emails.
In some more dire cases, the urgent emails have already passed (or maybe never came), and something their software depends on has literally stopped working. By the time things get serious, there’s often five to 10 years of work to catch up on. It can be very expensive, or even potentially impossible.
Oil Changes
Most drivers know they need to get periodic oil changes for their cars. Doing it with reasonable frequency keeps the engine humming along in better condition. Neglecting it entirely degrades the engine and can lead to failure.
Much like oil changes are now required less often than they were when I was a 20-something, software also used to require more attention than it does today. But simply because it requires less doesn’t mean you can get away with none.
Software might need several types of maintenance, such as checking and cleaning out accumulated logs. It might be replacing some small components, such as updating a library that now has security advisories with its patched version.
“Check Engine” Lights
To someone who just wants to drive their car (it’s me), a “check engine” light is probably one of the most infuriating things ever. It’s opaque. I can get a little bit of information as a car amateur with a code reader, but that doesn’t necessarily help me fix the issue. But they exist for a reason. They’re there to say something is out of whack. It might not be a big deal, or it might be a sign that something needs attention.
Similarly, good monitoring, set up by and reviewed by someone with experience, will alert you that something might be amiss, and you should check it.
Rebuilds
I know I’m stretching this car analogy to—maybe past—its breaking point, so please, just… stay out of the comments with that. But inevitably, software components end up just very old and broken down, and they require rebuilding.
The best time to do rebuilds is before you need them. Most providers and some of the bigger software dependency teams offer support schedules that let you know that they’re still maintaining them.
You can take your time and prepare, rebuilding small parts a little at a time instead of finding out the pile of old software is huge, expensive, and disruptive to work on.
Watch out if you wait too long, though—and, with the speed of software changes, “too long” is often counted in single-digit years. Part of the expense could also simply be that the software a developer could easily load and check out five years ago is extremely difficult to get running on a modern computer.
This is often the first act of the modernization engagements I work on. In more than one recent project, I booted up some “ancient” (in computer years) unsupported versions of Linux to get the code off the ground before I could start replacing parts of it and running it on modern computers.
What can you do?
Much like you’d get a good mechanic who can not just change your oil, but give you recommendations on future maintenance and warnings about the future, a software development professional with experience is a must.
Obviously, we can do that sort of thing here! If you’re already behind the eight ball, we can help with the big work of evaluating and modernizing something that’s in need of a lot of love and attention.
We also help folks on a continuous basis, spending a little time every month to check up on their software and make those smaller improvements now, before they become very expensive and cause downtime. We can also make small changes along the way in an engagement like this, responding to how users are interacting with your software and making it nicer to work with. You can also—and we may recommend this, and can help you out with it—add a software developer to your staff who will be responsible and accountable for this important work.
Computer technology keeps moving. Things that worked yesterday won’t necessarily keep working today, for all kinds of reasons.
Engaging folks with experience, who care about your software and want it to keep humming along, are not only necessary, but critical to having the best possible experience with the investment you made in building it in the first place.
Your software isn’t done helping you, after all. Keeping it in good shape will ensure it still helps you for a long time to come.