Digital transformation often feels like a frantic race to devise more scalable, flexible, and resilient enterprise IT systems that also support innovation and keep customers happy. But when it comes to making software development decisions, the constant need to react and respond in the moment can lead to short-term thinking. One of the most common pitfalls we see is organizations struggling with "technical debt." 

The decades-old metaphor of technical debt relates to the constant effort required to keep software sufficiently high quality and cost effective. It is usually the trade-off associated with choosing a quicker, more tactical solution over something that aligns to the longer strategic time frame, with the intention that this can be corrected later.

Even if you only have a small amount, technical debt accrues interest. If it's left unserviced, you can quickly find yourself dedicating almost all of your resources to servicing the debt, with little hope of repaying it quickly. But, just as with other forms of credit, technical debt is sometimes the only approach for a team. Getting new features out to market is beneficial for customers and can boost productivity and revenue, and sometimes the consequence of waiting is worse than taking on the debt.

Even for the best maintained systems, it's still possible for technical debt to appear and accrue based on external changes and market demands. It’s not always easily linked to a conscious decision or trade-off that we made and can sometimes feel like a parasitic drain on your team that is hard to pinpoint.

Based on our conversations with our customers, we’ve crafted three images that we feel collectively articulate the reality of technical debt and some ideas of how you might keep it in check.

1. Understand where the cracks lie

Today, most platforms and systems are a complex orchestration of smaller parts, as is best practice for anything of scale. For this reason, technical debt can begin to manifest in a very slow decrease in output from teams. When interrogated in detail it's hard to pinpoint the issue, but when you look at the overall impact it's clear to see that something is not as it should be. Technical debt "stacks" and increases exponentially. Detailed metrics and responses to fluctuations are key to pinpointing where issues lie and prioritizing how to fix them.

To illustrate this, technical debt can be compared to a water utility with leaky pipes. Resources – in this case water – are pumped into a complex underground network. Although water flows through taps at the other end, you are unaware of how many cracks you have, where the holes are located, and how much is being wasted. If you don’t fix the problem early, you may be forced to rip out the pipes and start again. Pouring more water in isn’t the answer. Similarly, in the corporate world, it isn’t viable for businesses to throw more and more resources at the problem, using funds that could otherwise be channeled into innovation. Instead, address the urgent short-term inefficiencies and then formulate a plan to look after the long-term health of your systems. 

2. Cultivate and nurture your software

There are many architectural terms used to describe software engineering, but we see it as a more organic metaphor, such as managing a garden. In your project’s springtime, you enthusiastically spend a large sum at the garden center and work your soil. But, by failing to do regular maintenance, you end up with dead plants and a dense forest of grass and thorns, and more costly trips to the garden center. In contrast, your more diligent neighbor regularly tames and tends their urban oasis, ripping out weeds, and ultimately ending up with a far more enjoyable summer.

We often hear that software costs so much or that maintaining it requires a lot of time and effort. This idea originates from the dot.com era, when software gained the reputation of being cheap and easy to build, although in fact the software of the period tended to be of bad quality.

Businesses should therefore expect to factor in a percentage of time for maintenance and improvements requested by the developers. In some cases, this will be a specific time budget; in others, it's an understanding that developers will need to “weed” as they go.

3. Assess the long-term financial sense

Software, like any technology, can quickly become dated and obsolete, therefore owning legacy technology is a natural part of running a successful business. The issue arises when software is left unchanged, so it no longer fits properly and tends to stop working. This can have serious implications in today’s complex software ecosystems, where one small glitch can impact many other areas of the architecture.

Maintaining software is an ongoing investment and could be compared to owning a classic car. From tightening bolts or to changing the oil regularly, it needs regular proactive maintenance. One common problem is that the parts are no longer available or can only be sourced at a premium through specialist vendors. You can make your own parts and patches but, at some point, you have to weigh up the long-term financial viability. Luckily, replacing software architecture isn’t driven by the same nostalgic pain as retiring a classic car. But once you have decided it makes better financial sense, many other factors come into play, such as making sure you begin the process by thinking about your people.

Final thoughts

Like real debt, paying off technical debt early on through maintenance and planning avoids issues from spiraling problems. Luckily, modern software development processes capture enough information to keep an eye on how much technical debt you are accruing and how you need to invest in reversing the situation, so that change can continue to be made efficiently and safely with manageable risk. It is now possible to see when parts of the software are starting to leak, grow weeds, or need bolts to be tightened.

Most importantly, the notion of technical debt allows businesses to measure how fast they can change, but without the speed of growth coming at an unexpected cost. It can also serve as a reminder to constantly evaluate which systems and applications bring the most value to your organizations, to recognize which merit the most time and resources, and can support innovation.