Saving software: why technical debt doesn't pay

abstract data flows / data streams
Gonin / Getty Images

Software applications get developed, but they also change, over time. Part of that essential progression, augmentation and enhancement of software code means that old code is replaced and eradicated. More often though, those older elements of the software code-base end up hanging around as ungainly appendages and obstructions in the central engine room of any given application's DNA.

These carbuncles of code are what we call technical debt.

The expression (actually, it's a metaphor, isn't it?) technical debt was coined by programming guru Ward Cunningham, who has explained that the metaphor is intended to draw comparisons with real world spending on a credit card, where obviously people can rack up debt that needs to be repaid.

In the case of software technical debt, the repayment process means that the developers on the team have to 'refactor' code and rebuild sections or sub-sections of an application. Let's examine some of the current issues, but first go back and understand what Cunningham was expressing in more precise terms.

 

What is technical debt?

"I think that there were plenty of cases where people [developers] would rush software out the door and learn things but never, never put that learning back into the program. So my debt analogy comes from borrowing money… and thinking that you never have to pay it back," said Ward.

"Of course, if you do that, you know, let's say with your credit card, eventually all your income goes to interest and your purchasing power goes to zero. By the same token, if you develop a program for a long period of time by only adding features and never reorganizing it to reflect your understanding of those features, then eventually that program simply does not contain any understanding at all and all efforts to work on it, take longer and longer. In other words, the interest is total and you'll make zero progress," he concluded.

Software applications get developed, but they also change, over time. Part of that essential progression, augmentation and enhancement of software code means that old code is replaced and eradicated. More often though, those older elements of the software code-base end up hanging around as ungainly appendages and obstructions in the central engine room of any given application's DNA.

These carbuncles of code are what we call technical debt.

The expression (actually, it's a metaphor, isn't it?) technical debt was coined by programming guru Ward Cunningham, who has explained that the metaphor is intended to draw comparisons with real world spending on a credit card, where obviously people can rack up debt that needs to be repaid.

In the case of software technical debt, the repayment process means that the developers on the team have to 'refactor' code and rebuild sections or sub-sections of an application. Let's examine some of the current issues, but first go back and understand what Cunningham was expressing in more precise terms.

 

What is technical debt?

"I think that there were plenty of cases where people [developers] would rush software out the door and learn things but never, never put that learning back into the program. So my debt analogy comes from borrowing money… and thinking that you never have to pay it back," said Ward.

"Of course, if you do that, you know, let's say with your credit card, eventually all your income goes to interest and your purchasing power goes to zero. By the same token, if you develop a program for a long period of time by only adding features and never reorganizing it to reflect your understanding of those features, then eventually that program simply does not contain any understanding at all and all efforts to work on it, take longer and longer. In other words, the interest is total and you'll make zero progress," he concluded.

In fast-paced commercial environments, it's not hard to imagine that once an application has been pushed to a live production environment, it has to be kept running. Enterprises will often be too focused 'just keeping the lights on' to worry about how they should be maintaining their code-base as a more dynamic living thing.

A concentration of modernization frustrations

The magical soothsayers at analyst house Gartner have said that technical debt poses a risk to software modernization i.e. the process of pushing applications to a cloud-native (often mobile-first) existence with the ability to plug into all the 'modern' advantages that come with AI-based automation, Robotic Process Automation (RPA) and autonomous control intelligence.

"Managing technical debt in large legacy environments is the top challenge for infrastructure and operations leaders," revealed the Gartner wizards. "[Our Accelerate State of DevOps 2019 report highlighted the damaging impact it can have on productivity] because respondents with high technical debt were 1.6 times less productive, [while] the highest performers were 1.4 times more likely to have low technical debt."

As a blog for the Software Engineering Institute at Carnegie Mellon University (CMU) puts it, "In their haste to deliver software capabilities, developers sometimes engage in less-than-optimal coding practices."

Also vocal on this subject is Gaurang Torvekar in his role as CEO and co-founder of Singapore headquartered developer skills assessment platform company Indorse. Torvekar thinks that part of the whole issue surrounding the concept of technical debt is that no one is really sure how it manifests itself in solid, definable, quantifiable, trackable and manageable terms.

"Asking two different software engineers where their code-shop's technical debt is stemming from and you will get two different answers. The institute at [the above mentioned] CMU ran a field study, with one of the questions attempting to understanding and uncover the core issues at hand here and as the CMU confirms, the results highlight that neither developers nor their managers agree on a clear understanding of what is meant by the metaphor and its impact on each individual project," said the Indorse CEO.

 

Cutting corners creates code cost

This lack of understanding can be a challenge, particularly when engineering managers are trying to explain to product marketers why something might take so long. To come back to our metaphor structure again, technical debt is the added complexity, or the interest you have to pay, that is created when corners are cut.

To add more than a pennyworth of clarity to the issue, Matthew Sinclair, VP of engineering at BCG Digital Ventures has said that, "Technical debt is akin to taking out a loan, denominated in time, that you bet will pay off for you in terms of learning and velocity at some point in the future." But betting on being able to fix a leaking ship halfway into a voyage is a dangerous bet, obviously.

Group technology director at business utility switching platform company Prestige Worldwide is Thomas Dittmer. Explaining that he sees two types of technical debt playing out in the real world, Dittmer says that one form comes about where teams are actually aware that they have knowingly taken on more than they can initially repay, because they're deliberately trying to run as fast as possible. The other second type is created more naturally and organically, simply because 'life just moves on' and obsolescence happens as end user use cases evolve and change so that more is asked of an aging application.

The question arises then, how much technical debt should any single (or group-connected) development team take on and bet on? Indorse for its part hosts an engineering leaders question panel to attempt to provide answers, or perhaps even just some solid clues to clarify.

Dittmer notes that his teams have run tracking systems to log every piece of new code committed (or refactored or redacted or rationalized in some other way) in order to flag its potential to add to the technical debt payoff pile. That way, they could review the state of the code-based on an ongoing basis and prioritize what they should work on.

Does all technical debt need repayment?

Being as thorough as possible here, we should question whether all technical debt does in fact need to be repaid. After all, many people live with a 'workable' debt balance on their credit card every month without necessarily always paying it off to zero.

ThoughtWorks developer Martin Fowler blogs to say that if technical debt doesn't slow engineers down, perhaps it does not necessarily need to be addressed. He suggests that fixing the problem for one feature may actually not provide any material gains, if the fix took longer than the feature itself. He suggests that the fix is only really cashable if it could apply to multiple features that an engineer might reap benefit from.

Of course, the potential benefit of a code refactoring process can't be determined if technical debt itself isn't being measured. Engineering manager at Improbable, Oswaldo Hernandez Perez has said that it's indeed hard to measure technical debt objectively, thanks to its vague definition. He explains that there are some signs that can be used to track the impact of technical debt, such as an increase in customer support contact rate or number of incidents. However, engineers need to be mindful of additional factors when considering these as technical debt indicators.

A means to an end?

This whole discussion comes down to the need to demonstrate the value of getting rid of the technical debt. Like everything else in business, there needs to be a quantifiable return on investment. If, as we suggest here, the work required to fix the problem will not have a direct impact, does it justify the use of resources?

One way of working that out is to identify a tangible, explainable benefit. We can say that it's extremely important to have technical debt in a road map and be able to explain the value of fixing it. Teams should be able to explain what the benefits are, what the risks are and what the central implications, wider ramifications and associated frustrations are of it existing.

Technical debt in software development is a challenge and it can complicate what is already a complex task. The key to managing it is to be able to identify real, tangible value, with benefits that are clear to others. If that is not possible, then it is time to consider whether it needs to be dealt with at all - and you can bank on that.