This is part three of a seven-part series: “The Seven Deadly Sins of Enterprise Software,” which was initially presented at SDL Connect in November of 2019.
There are many sins of software, but few of them are deadly. Only a handful of mistakes in enterprise software will have long-term ramifications for how your business operates. Last time we talked about how Data Hoarding is an easy trap to fall into but can be avoided by first deciding what questions you have for your data.
Another of these "deadly sins" is “Software Negligence”; let's talk about what it is and what we can do about it.
Entropy is not Neglect
Software Entropy
All software experiences entropy, a natural degradation over time. Software entropy happens because memory fills up, hardware wears down, operating systems improve, and users expect everything to stay the same.
As machines wear down and operating systems wear up, the software caught in the middle must go somewhere. Good software vendors do their best to update their programs. Still, eventually Excel loses some of that pep when resolving formulas. Outlook takes a tad longer to get those emails. Your favorite game on Steam starts to lag. While this is happening, programming languages and programming platforms change, inevitably leaving some software behind.
So now we have a definition for software entropy:
The natural breakdown of software over time
Recognizing that software entropy is natural helps us see how it contrasts with software negligence.
Software Neglect
Neglect stands apart from entropy because it is a willful act. It’s how we respond to the state of some software.
Failing to take care of software by not upgrading it, patching, hotfixing it, or performing recommended maintenance that keeps it running optimally
Software negligence is either an act of commission or omission. We make an intentional choice to not perform upgrades and patches that we know are needed. Or we decide to ignore any routine maintenance the software might need.
It’s not the maintainer’s fault if there’s a new operating system that the hardware can’t support. Nor is it the maintainer’s fault if the OS can’t support upgrades for the software.
But suppose the maintainer isn’t routinely applying upgrades or patches or even bothering to clean out unused files and clutter. In that case, that software is going to an early grave.
Software Negligence Snowballs
I have a (not-so) fond memory of a project involving SDL Tridion. We were having all sorts of challenges, and at one point, I checked to see how many hotfixes and patches we had. It was somewhere in the range of 50.
The project didn’t start that way. It was, at one point, a brand-new installation. As the project progressed, the focus went to other aspects of the project instead of maintaining the core software. The sysadmins recognized the growing pile of available hotfixes as a massive time-suck. They ultimately decided that there were too many to do any.
When we started to experience issues that we suspected were due to many uninstalled hotfixes, we asked the devops team to apply them. The response was, “tell us which one, and we’ll do it.”
We couldn’t say for sure which hotfix would solve our problem because we had so many of them and so many potential fixes that could solve them.
Their act of omission (ignoring updates) led to their act of commission (refusing to do updates).
Ultimately, we got our 50+ hotfixes and updates. It took our sysadmins almost two solid weeks to apply them across all environments.
Course Correction
First, we must recognize that the opposite of software negligence is software maintenance.
Next, we must be mindful that software is made by humans; it’s not perfect, and it never will be perfect. We can’t blame the software for needing to be updated; that’s just the way it goes. Snow is going to snowball.
But we should also be mindful that a backlog of past-due updates is not why we can’t do those updates. Snowballs are going to snowball, too.
Instead, we should understand what the administrators I dealt with so long ago didn’t: It was always going to take 80 hours to do those updates. Their choice wasn’t if they’d do updates, but when.
We avoid software negligence by making software maintenance a habit:
- Include maintenance into yearly and quarterly budgets
- Schedule quarterly audits of packages and libraries in codebases to see if they need updates
- Allocate a small number of hours in every sprint for updates
If software maintenance isn’t a habit your team wants to keep, remember that someone else is happy to make it one. Cloud architectures are a great solution as they offload the responsibility and burden to someone else.
Software entropy is natural, software negligence is willful, and software maintenance is habitual; good habits will keep the entropy at bay.
