DEVOPSdigest

Technical debt is an issue that dogs engineering but is a reality of everyday work life.

A Gartner report from March 2020 said that "managing technical debt in large legacy environments is the top challenge for infrastructure and operations leaders", while the Accelerate State of DevOps 2019 report highlighted the damaging impact it can have on productivity — "respondents with high technical debt were 1.6 times less productive, and that the highest performers were 1.4 times more likely to have low technical debt."

If it's such a problem, why does it exist? 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."

But what actually is technical debt? Part of the issue surrounding the whole concept is that no one is really sure — asking two engineers will produce two different answers. The SEI at CMU ran a field study, with one of the questions covering understanding of the concept, and its "results confirm the widely held belief that neither developers nor their managers share a clear understanding of exactly what is meant by the metaphor and what it means for their project."

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. Put simply, technical debt is the added complexity, or the interest you have to pay, that is created when corners are cut.

To add a bit of clarity to the issue, Matthew Sinclair, VP of engineering at BCG Digital Ventures, explains 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."

For Thomas Dittmer, Group Technology Director at Prestige Worldwide, there are actually two types of technical debt: "one that you've actually knowingly taken on because you're trying to run fast, and the other type is 'life's just moved on,' and you turn around and think 'oh that's not very good is it,' what we did a year ago or six months ago."

Thomas was speaking during the Indorse Engineering Leaders Online Panel, in response to a question on how the panellists decide how much technical debt to take on and when they pay it back. In response to the first query, Thomas suggested tracking technical debt. "I used to run a system where I'd have all the team leads log everything they had that they thought was technical debt and we'd review it, and we'd prioritize it and understand what we'd work on."

But when should it be paid back? It's a question that challenges many organizations — surely anything bad should be taken out of the business as quickly as possible?

Not necessarily, suggested Thomas, in an argument echoed in a blog by Martin Fowler back in May 2019. The former felt that if the technical debt doesn't slow engineers down, perhaps it does not necessarily need to be addressed, while the latter pointed out that fixing the problem for one feature may actually not provide any material gains, if the fix took longer than the feature itself — it was only when the fix could apply to multiple features that an engineer might reap the benefit.

Of course, that potential benefit can't be determined if technical debt isn't being measured. Oswaldo Hernandez Perez, Engineering Manager at Improbable, noted that "it's indeed hard to measure technical debt objectively," thanks to its vague definition. He explained 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.

It 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 Fowler and Thomas allude to, 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. Sarah Vang Nohr, Engineering Manager at Trustpilot explained that "It's extremely important to have [technical debt] in a road map and be able to explain the value of fixing this tech debt. You should be able to explain what the benefits are. If you can explain that the benefits are you can deliver 10% faster then that's understandable to others." If you can't, then it's time to take a step back and think about what you are trying to achieve.

Technical debt in software development is a challenge, and it can complicate what is already a complex task. As the panellists noted, 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.