Why Managing Technical Debt Is About Identifying Value
March 30, 2021

Gaurang Torvekar
Indorse

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.

Gaurang Torvekar is CEO and Co-Founder of Indorse
Share this

Industry News

May 19, 2022

Jellyfish announced the launch of Jellyfish Benchmarks, a way to add context around engineering metrics and performance by introducing a method for comparison.

May 19, 2022

Solo.io announced the addition and integration of Cilium networking into its Gloo Mesh platform, providing a complete application-networking solution for companies’ cloud-native digital transformation efforts.

May 19, 2022

Aqua Security announced multiple updates to Aqua Trivy, making it a unified scanner for cloud native security.

May 18, 2022

Red Hat unveiled updates across its portfolio of developer tools designed to help organizations build and deliver applications faster and more consistently across Kubernetes-based hybrid and multicloud environments.

May 18, 2022

Armory announced public early access to their new Continuous Deployment-as-a-Service product.

May 18, 2022

DataCore Software announced DataCore Bolt, enterprise-grade container-native storage software for DevOps.

May 17, 2022

DevOps Institute, a global professional association for advancing the human elements of DevOps, announced the release of the Upskilling IT 2022 report.

May 17, 2022

Replicated announced a host of new platform features and capabilities that enable their customers to accelerate enterprise adoption of their Kubernetes applications.

May 17, 2022

Codefresh announced that its flagship continuous delivery (CD) platform will be made accessible as a fully-hosted solution for DevOps teams seeking to quickly and easily achieve frictionless, GitOps-based continuous software delivery in the cloud.

May 16, 2022

Red Hat announced new capabilities and enhancements across its portfolio of open hybrid cloud solutions aimed at accelerating enterprise adoption of edge compute architectures through the Red Hat Edge initiative.

May 16, 2022

D2iQ announced a partnership with GitLab.

May 16, 2022

Kasten by Veeam announced the new Kasten by Veeam K10 V5.0 Kubernetes data management platform.

May 12, 2022

Red Hat introduced Red Hat Enterprise Linux 9, the Linux operating system designed to drive more consistent innovation across the open hybrid cloud, from bare metal servers to cloud providers and the farthest edge of enterprise networks.

May 12, 2022

Couchbase announced version 7.1 of Couchbase Server.

May 12, 2022

Copado added Copado Robotic Testing to Copado Essentials.