How to Manage Aging Software
A big theme across our projects recently has been how to deal with "old" software. It's an unfortunate fact that software ages quickly. We all know "tech moves fast," but in that trite sentiment it's easy to lose sight of the reasons software falls out of date and what we can do about it.
Aging Software Isn’t That Old
What we've come to see as "old" software is often no more than 3-4 years old. Those of you who have this issue already know what I'm talking about, and those of you who recently completed a build or are embarking on a new one: I hope this helps you prepare for what's to come and avoid the worst outcomes.
What's so wrong with old software?
Sometimes nothing. Left undisturbed, computers will happily do exactly the same thing over and over forever. This is the incredible utility of software. Endless reliability and scalability are two of the main reasons why we build applications in the first place.
Why Software Becomes Outdated
But businesses - and tech startups especially - require software that can be changed over time. The pace of change needs to at least match the pace of the world around us and the markets in which we operate.
So when our team has tackled old software, the main problem we've encountered is that the pace of change is sometimes painfully, excruciatingly slow. Too slow for what the business needs or can afford.
This is incredibly frustrating to everyone involved. Business owners become desperate to understand what can be done to get back on track. They lose trust in their team and seek other options. Faced with this, many engineers will throw up their hands. Frustrated that they cannot do their best work and under pressure to deliver, they will conclude they can't work in such conditions.
It's at this point people start talking about throwing it all away and doing a rewrite. It's tempting, but I strongly advise against rewrites as a first resort. That is a topic for another day.
How does software end up in such a state?
Friction against change can arise almost anywhere in the software stack. In my experience, the biggest source of friction is the application's dependencies and the downstream impact this has on the development process.
How Dependencies Create Outdated Software Systems
"Dependencies" is a broad term that includes any other software, system, or service that your application depends on to function properly. In brief, this includes the operating system (usually Linux in the case of web apps), the programming language, third party APIs, and other open source software packages that developers install to quickly add features to your app.
What happens over time is that your app's dependencies - the software it was built to be compatible with - fall out of date and become incompatible with each other. Many of the key dependencies listed above are open source software (OSS) and often free. They are constantly being updated, whether to fix things, add things, upgrade their own dependencies, or get ahead of security issues. Sometimes the (often unpaid) package maintainers decide to stop updating their software. Thus, it also gradually becomes incompatible with the latest progress in the OSS ecosystem.
For better or worse, open source software is the foundation of the modern software stack.
Researchers at Harvard Business School recently published a study estimating the demand-side value of Open Source Software at over $8 trillion. Yes, trillion with a 'T'. They estimate that without OSS, companies would have to spend 3.5X more to develop software. That honestly seems like an understatement. I cannot imagine building apps as quickly or reliably as we do without these tools.
“We estimate the supply-side value of widely-used OSS is $4.15 billion, but that the demand-side value is much larger at $8.8 trillion. ”
How to Mitigate the Risks of Dependencies in Software
OSS offers major benefits to productivity but carries with it the risk that the ground will constantly shift beneath you. There are plenty of things that can be done to mitigate this risk. For example, engineers should think twice before adding new dependencies. Application structure should be kept simple and depend on a minimal amount of tried and true software. Those are best practices, but understandably not always practical when moving quickly.
Now that we've touched on some problems, here is some practical advice on how to avoid the worst impacts of aging software:
Migrations, not rewrites - Treat your application as a living organism. Don't kill it and then try to resurrect it. Instead, perform minimally invasive "surgeries" to gradually upgrade and resolve problems over time in parallel to new feature development.
Prioritize a healthy engineering process - Our Engineering Capabilities Checklist (ECC) enumerates the practices that make for a healthy engineering process. These are designed to ensure that you are always in a place to make changes to your application when you need to. The most critical capabilities related to this topic are the ability to make working copies of your app and to reliably deploy your app.
Leave room in your road map to identify trouble spots and make proactive fixes. The Software Quality Scorecard (SQS) is our tool for tracking and prioritizing long-run issues of quality and maintainability.
If the topic of outdated software feels all too familiar and you would like some help getting your software back on track, contact us to see how we can get you moving in the right direction.
Enjoy this article? Sign up for more CTO Insights delivered right to your inbox.
