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

January 26, 2023

Ubuntu Pro, Canonical’s comprehensive subscription for secure open source and compliance, is now generally available.

January 26, 2023

Mirantis, freeing developers to create their most valuable code, today announced that it has acquired the Santa Clara, California-based Shipa to add automated application discovery, operations, security, and observability to the Lens Kubernetes Platform.

January 25, 2023

SmartBear has integrated the powerful contract testing capabilities of PactFlow with SwaggerHub.

January 25, 2023

Venafi introduced TLS Protect for Kubernetes.

January 25, 2023

Tricentis announced the general availability of Tricentis Test Automation, a cloud-based test automation solution that simplifies test creation, orchestration, and scalable test execution for easier collaboration among QA teams and their business stakeholders and faster, higher-quality, and more durable releases of web-based applications and business processes.

January 24, 2023

Harness announced the acquisition of Propelo.

January 23, 2023

Couchbase announced its Couchbase Capella Database-as-a-Service (DBaaS) offering on Azure.

January 23, 2023

Mendix and Software Improvement Group (SIG) have announced the release of Mendix Quality & Security Management (QSM), a new cybersecurity solution that provides continuous deep-dive insights into security and code quality to immediately address risks and vulnerabilities.

January 23, 2023

Trunk announces the public launch of CI Analytics.

January 23, 2023

Panaya announced a new Partnership Program in response to ongoing growth within its partner network over the past year.

January 23, 2023

Cloudian closed $60 million in new funding, bringing the company’s total funding to $233 million.

January 19, 2023

Progress announced the R1 2023 release of Progress Telerik and Progress Kendo UI.

January 19, 2023

Wallarm announced the early release of the Wallarm API Leak Management solution, an enhanced API security technology designed to help organizations identify and remediate attacks exploiting leaked API keys and secrets, while providing on-going protection against hacks in the event of a leak.

January 19, 2023

ThreatModeler launched Threat Model Marketplace, a cybersecurity asset marketplace offering pre-built, field-tested threat models to be downloaded — free for a limited time — and incorporated into new and ongoing threat modeling initiatives.

January 18, 2023

Software AG has launched new updates to its webMethods platform that will simplify the process by which developers can find, work on and deploy new APIs and integration tools or capabilities.