The “triple threat” part one: Maintenance

“We’ve not made any changes, but it stopped working”.

This is a phrase I’ve heard more times than I care to count. It is typically uttered by a business owner, frantically reaching out for support because the mission-critical software their business relies upon has given up the ghost. At best their staff are sat twiddling their thumbs unable to get on with anything, but at worst, they’re down thousands of pounds a day due to lost sales.

As a company, Foxsoft specialise in providing support and maintenance to help avoid exactly this type of situation. We see there being three threats to that mission-critical (or any) software: maintenance, technical debt, and lack of documentation. In this article, we’re looking at the first of these: maintenance.

Imagine the scene: a business hires a developer on a short-term contract to write a piece of software – maybe a custom billing package, or an e-commerce solution – the developer writes the software, adds feature after feature until it solves the problem, provisions the server, deploys the software, demos how it works to the company, and moves onto the next client.

The software works. It was built using the latest versions of the tools and framework available at the time and deployed to a server running the most up-to-date operating system, programming language, and database. Everyone is happy, at least for a time.

The thing about software, as eloquently explained by Foxsoft head honcho Andy Henson, is that it isn’t static. And if we stop moving forward, we actively start going backwards.

Maintenance

Moore’s Law – named after Gordon Moore, the co-founder and CEO of Intel – is an observation that the number of transistors in a dense integrated circuit doubles about every two years. Or, to put it a bit more simply, the amount of processing power possible doubles about every two years.

With this increase in power comes increased ability and new ways of utilising it, which software maintainers implement in their packages and release as updates. Sometimes these are purely performance enhancements which might avoid having breaking changes, but other times it’s a paradigm shift – a whole new way of solving a problem – which results in sweeping changes and dumping of technical debt (more on this in the next article) causing a cascading effect wherein breaking changes to low-level systems necessitate changes to the higher-level systems which rely on them, which in turn continues up the chain, affecting every piece of software in its path.

Securing vulnerabilities

But performance enhancements aren’t the only source of change. Try as software developers might, mistakes happen, and there is many a shady character ready and able to take advantage of the vulnerabilities introduced via such mistakes.

Thankfully the industry is typically very good at self-regulation, with proper procedures for reporting any vulnerabilities discovered and distributing fixes, but this takes time and effort. In our case, this time cost is typically the time required to perform regular audits of the software and packages in use by an application, and the effort to implement and test the fixes before and after deploying them.

Whereas performance enhancement updates may be possible to ignore for a time (often justified as if it’s not broken, don’t fix it), vulnerability fixes cannot be ignored, for reasons which I hope are self-evident.

But ignoring the performance updates isn’t something which can happen forever, as given enough time (time which passes far quicker than might be expected) they’ll fall out of support, meaning fixes for vulnerabilities won’t be available. In fact, often a rogue entity might discover an exploit in an old, soon to be unsupported, package, and wait until it is out of support before they’ll attack it, knowing that the effort to fix it is exponentially increased, giving them more time to exploit it.

It is because of this we’ve named Maintenance (or a lack of) as our first threat, and as an ongoing concern on all our client’s roadmaps.

In our next articles, we’ll look at technical debt and lack of documentation as the other two threats to your company’s software.