Paying down technical debt is a problem that won't go away for businesses

Engineers understand all too well that machines, and their components, become less efficient over time.

Whether it is a car or an electric motor, parts wear down and eventually, need to be replaced. Engineers and manufacturers design tolerances for this into their designs, along with maintenance schedules and timescales for replacing parts.

Although it might not seem obvious, the same happens with computer software. Applications become less effective over time, not because of physical wear and tear, but because of changes and additions made to code.

This is known as technical debt. Unless developers address it, software becomes less and less usable, and more and more expensive to maintain.

And the problem appears to be increasing.

“Development lifecycles are getting shorter,” says Stephen Gailey, director of systems architecture at Gurucul. “Organizations are much more focused on getting features out to customers quickly and so short-term decision making drives product management more than long term planning. The problem you have is that organizations tend to hide the issue until it is killing them.”

The concept of technical debt first came to the fore in 1992. The US-based software developer Ward Cunningham used the term to explain how taking short cuts in software design builds up costs later on. That is, unless developers take steps to update the software, or “pay down” the debt.

Since then, though, technical debt has taken on a broader meaning, covering legacy technology, software maintenance, vulnerability management and documentation (or, more likely, a lack of it). In the UK, a rising number of IT decision makers forecast rising technical debt, particularly as they rush to adopt AI.

Computer science researchers such as Steve McConnell have split technical debt into two halves: intentional and unintentional debt.

Technical debt: Making shortcuts

Intentional technical debt are shortcuts taken by developers, usually to hit targets such as release schedules, user demands, or budgets. They know the code is less than ideal. But it does the job it needs to do, at the expense of needing more maintenance or development later.

Unintentional technical debt, on the other hand, comes from errors and shortcuts in software design. These are not conscious trade offs, but rather problems that could, and probably should, have been avoided.

The consequences of both forms of debt, though, are software that is harder and costlier to maintain.

“A good thought exercise is to inventory all the cut corners, the decisions you didn’t make, the updates and changes you postponed, and the investments not made over the past decade,” technology consultant Wim Reyes tells ITPro. “The effects are compounding.”

And as with all debt, technical debt compounds, or builds up over time. In this way, the longer software operates, the more debt it accrues. This explains why technical debt is so often associated with older or legacy software, although of course it is possible to have older software that runs perfectly well.

But another aspect to technical debt is the impact of modifications, changes in functionality, or even scope for an application over time.

These changes can lead to poorly designed additions to code, as older software is adapted to take on tasks for which it was never designed. Even well-written applications will show the strain if they have new functionality grafted on to an old code base.

And expanding the scope of an application can reveal design compromises that were not obvious when designers first created the software. Modern applications make extensive use of APIs, for example. These were not commonplace 20 years ago. Today’s applications also need security measures that the original designers would not have been able to anticipate.

Unsurprisingly, adapting older applications to these modern requirements adds to costs, and reduces reliability.

“Technical debt is an even bigger issue than it has been, even if it is overshadowed by cyber or the dreams of AI,” explains Jaco Vermeulen, CTO at consultancy BML. “Both of those are actually big drivers to focus on the boarding but important foundations and remediate tech debt across the domains of core IT, infrastructure, enterprise systems and customer interfaces.”

Technical debt: Time and money

As Vermeulen points out, businesses often believe that they lack the budget – and especially the CapEx – to do more than keep IT systems running. Instead, they adopt a mentality of “if it breaks, we’ll fix it”, he says.

This, though, just perpetuates the problem. Recent research carried out for Pegasystems found that 44% of UK companies spent between 26% and 50% of their time maintaining legacy systems. A further 26% spent between half and three quarters of their time on legacy.

In one in four enterprises, legacy systems also accounted for between six and ten outages, performance issues, or security breaches; in five per cent of companies, the total was more than 20 incidents.

In one in four enterprises surveyed, legacy systems also accounted for between six and ten outages, performance issues, or security breaches; in five percent of companies, the total was more than 20 incidents.

And legacy systems still account for a large percentage of the technology in daily use. Pegasystems found that 29% of teams used one to five legacy applications and 34% used 6-10 legacy packages.

This shows the scale of the challenges posed by legacy systems; Pegasystems found that the vast majority (88%) of CIOs it surveyed believed that technical debt was making it harder for their organizations to keep up with more agile competitors.

“CIOs can tackle technical debt by shifting its perception from a mere IT nuisance to a strategic risk that impacts revenue,” Lee McClendon, chief digital and technology officer at Tricentis, tells ITPro. “This starts with translating technical issues into business impact, using metrics such as downtime, customer churn, or delayed releases to make the case.”

Enterprises, he suggests, need to focus on “smarter decisions earlier on in the development process”, as well as modernising those legacy systems. This will cost money. But failing to act inevitably ends up costing more.

Enterprises, he suggests, need to focus on “smarter decisions earlier on in the development process”, as well as modernising those legacy systems. This will cost money. But failing to act inevitably ends up costing more.

“Ultimately, reducing technical debt is not about chasing perception,” says McClendon. “It is about building systems that can move fast without breaking under pressure."