Technical Debt Does Not Include Aging Technology

People often say one form of technical debt is due to the aging of technology and architecture. It is not!

Let's talk about a common mix-up in the tech world: the difference between technical debt and the simple aging of technology. It's a hot topic, I have seen argued in many posts on technical debt. With the pace at which technology evolves, it's easy to see how today’s innovations quickly become tomorrow's relics. But here's where things get interesting – aging technology is not technical debt. Calling it so might be missing the mark.

The aging of technology is a given. Think about it – the programming languages, tools, libraries, and architectures we rave about today. They'll likely be on the nostalgia in a few years from now.  In a few years, some poor sod will be given the goal of modernising the product based on the technology we thought bleeding edge today.  This process doesn't automatically spell trouble for organisations, but it does bring us to a crucial point: the difference between natural aging and actual technical debt.

So, what is technical debt in this scenario?

It's not about using an old version of a library or sticking with a design pattern that's fallen out of fashion. True technical debt is more about neglect; that is, trading quality for time. It happens when we let our products age without giving them the care they need to stay relevant and current; it is trading time to maintain the product and instead focus on other things. Imagine not updating your car with the necessary maintenance; even minor repairs can eventually become major headaches.

I've been building software products for over 30 years, and one thing has stood out to me: actively keeping products current, allowing them to rot to the point they are useless. Having an architecture and flexible design makes it easier to maintain and change, and also prioritising high cohesion and loose coupling from the get-go. I've seen products that can evolve gracefully, easily embracing new language versions and libraries. This isn't just good practice; it's a strategy for staving off technical debt, allowing change in the future. It's futureproofing it.  The next step is to update the product with new technology versions as they emerge constantly.  When you design with change in mind, updating your system becomes a manageable task, not a monumental challenge.

But here's where many fall into a trap: leaving a product as is, hoping it'll somehow keep up with the times. This approach is akin to milking it dry, banking on its initial success without investing in its longevity. Over time, this neglect turns even the simplest updates into herculean tasks. That's the real cost of technical debt –the price we pay for choosing immediate convenience over the sustained health of our product.

A sidenote

Ward Cunningham, who coined the term "Technical Debt," has described it as thinking about the trade-offs between delivering software quickly and the future cost of having to go back and improve it.  These are trade-off decisions to take shortcuts and fix them at a later date.

Martin Fowler also elaborates on Cunningham's concept, emphasising that technical debt is like financial debt in that the "interest" manifests as the additional effort required to add new features due to the existing deficiencies in the system.  With Fowler’s contribution, the longer it ages and is not dealt with, the harder and bigger the problem becomes, thus costing significantly more to repair than to do it right. 

Similarly, scrum.org defines technical debt as “Trading quality for time” and its impact on future throughput and effort required to rectify the shortcuts taken. 

All these shortcuts and time not spent keeping the product healthy will come back and bite but at a higher cost.  My real-world experience has taught me that it will be at the most inappropriate time when it fails.

Wrapping up

So, let's not confuse the two. Aging technology? That's just the nature of the beast. But aging technology as technical debt? That's a choice of not maintaining the product and keeping it current, which is often costly. It's about letting our products deteriorate by not actively maintaining them and by not adapting to the changing tech landscape. As we navigate the complexities of software development, let's aim for more than just keeping up. Let's invest in architectures and practices that allow our products to age and thrive in an ever-changing world.  It requires a commitment to keep the product healthy.  It is more about not trading time to do other things and allowing the product to slip into a state where it becomes a problem.

Technical debt is a concept that's often misunderstood. Many people include aging technology into technical debt. This distinction is crucial for any professional in the tech industry aiming to manage their software's lifecycle effectively. Let's explore this nuanced terrain with a focus on clarity and insight.

Technical debt is not the fact that technology ages; instead, it is from choosing to ignore and not maintain the aging technology! A subtle but important difference.