I may live to regret this analogy.
But let’s consider this a PSA for the purpose of maintaining your software application . . . perhaps co-sponsored by your local ASPCA or Animal Rescue.
I frequently find that clients think of their applications like a very heavy piece of furniture — one of those uber-plushy, leather recliners. You buy it, you stick it in the corner, and, there it sits, comfy and dependable, aging gracefully in place for years until a spouse puts a foot down and insists that it be updated for a newer model. The chair is dragged to the corner or sold at a yard sale or hauled to the transfer station.
But software applications are not static products. Although they don’t respire, nor do they have pulses, they do tend — if neglected — to become diseased, collapse upon themselves, and die.
The reason for this is two-fold:
Technology itself is ever-changing, ever-evolving, ever-advancing, and technology does not have the attention span it once did. Software versions are updated constantly. APIs are deprecated. Libraries abandoned. Devices invented. Operating systems “sunsetted.” UI/UX needs go from turtles to touch-screen. And hackers don’t stop, ever, seeking new ways to exploit inherent flaws. Beyond that, user expectations drive applications into new (and necessary) realms – like the current demand for ADA accessibility compliance.
If an application has been around a few years, it’s likely that someone has had their fingers in the code or the database. Things happen to it in the heat of production use and those things, while taken by themselves, may initially seem harmless, eventually begin to make the application less performant, less stable, and more prone to issues. The notes in the application’s documentation begin to look a little “War and Peace”- like. These updates can also make tracking down issues harder: An issue may be caused by an OS update but a developer may have a surprise, on updating the code to support a newer OS, when all of those little updates interact with his or her updates unpredictably and the (bug) hounds are released.
The longer a code base is allowed to languish, the more the issues compile (ha!). A client’s user asks for a small modification and rather than thinking through the solution and implementing thoughtfully, a quick (and cheap) hack is done . . . and left. An API deprecates and rather than take the time to update it, the client chooses to let it stay, despite the warnings. Aging libraries and their dependences are left to crack and crumble. User-entered “garbage” gluts a database and festers.
At some point, like the Baobab tree, what was once small, breaks an application apart. Fixing the issues then becomes exponentially more expensive and time-consuming.
Even worse, as technologies are sunsetted and are no longer supported, security patches stop coming and this leaves the application open to hacking — like an unvaccinated adult in a room full of flu-carrying toddlers.
So, at the risk of offending cat lovers everywhere, I’ll say that rather than thinking of your application like a Barko Lounger, you should, instead, approach the care and maintenance of your application the way you approach the care and maintenance of your beloved feline.
Like a cat, your application does not need constant attention and nurturance. You can, if you must, go away for a few days and, with a clean litter box and enough food and water, Mr. Fuzzypants will be just fine upon your return, if a bit clingy.
But, you will need to schedule yearly vet visits and keep up-to-date on vaccines. As they mature, you’ll need to create a plan with your vet on how to support Mr. Fuzzypants through all phases of his nine lives. You’ll need to make sure he’s received his flea and tick medication or you’ll suffer the itchy, infestive consequences.
You’ll also need to pay attention and take the time to look. To listen. To be aware if something is wrong. To notice the odd new listless behavior. And then you’ll need to respond by taking Mr. Fuzzypants to the vet and getting a diagnosis and following the vet’s instructions.
Do this and Mr. Fuzzypants will spend many a happy year bopping you on the nose at 3AM and stealing your popcorn.
Likewise, your software needs attention: Commit to maintaining the application by updating it to the latest versions of the technologies it uses on a regular basis; incremental updates are relatively quick and painless. Take time at these updates to test the application thoroughly and fix any issues that arise. Since software is usually backward compatible for at least a few versions, this is usually pretty painless. It also might be a good time to insert some error logging into an aging application to make future debugging faster and easier.
Create a long-term roadmap for the application. Plan for feature extensions and for the need to update the UI/UX based upon user feedback and current needs.
If issues arise, address them immediately. If your users suddenly report that “the application has been flakey lately” this is a red-flag and isn’t likely to resolve itself. Get a developer in to look at the code before things go down in the middle of a critical process or deadline.
The other nice thing about maintaining your application is that it gives you a sane, non-emergency method for finding, evaluating, and building a trusting relationship with a developer.
Just remember, what’s true for cats is also true for software . . . and a lot of other things. Maintaining is easier than replacing; taking a few things a little at a time is far less risky than undertaking major repairs all at once, and committing to a plan of long-term care and maintenance means a far more enjoyable and long-lived relationship . . . be it with Mr. Fuzzypants or your application.
Spot the Vulnerability: Loops and Terminating Conditions In memory-unsafe languages like C, special care must be taken when copying untrusted data, particularly when copying it to another buffer. In this post, we\'ll spot and mitigate a past vulnerability in Linux\'s...