# How to Measure Technical Debt Before You Start Tackling It | LinearB Blog

> Learning how to measure technical debt will allow you to make sound decisions when thinking about software quality. Learn how in this post.

_This is a markdown rendering of a live HTML page on linearb.io, generated for AI/LLM consumption — it is not a markdown-only site. To get the full HTML page instead, request this URL with an explicit `Accept: text/html` header (no wildcard, no markdown preference)._

[Blog](https://linearb.io/blog)

/

How to Measure Technical Debt Before You Start Tackling It

# How to Measure Technical Debt Before You Start Tackling It

![Photo of Carlos Schults](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/logo-mark-lg?_a=BAVMn6ID0)

By [Carlos Schults](https://linearb.io/blog/how-to-measure-technical-debt#carlos-schults)

|

March 18, 2022

![fleur_d_Qf7_R_Zh_MOJU_unsplash_scaled_3bc4861919](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/fleur_d_Qf7_R_Zh_MOJU_unsplash_scaled_3bc4861919?_a=BAVMn6ID0)

[Technical debt](https://linearb.io/blog/technical-debt-ratio/) is one of the most enduring metaphors in the software world. There are plenty of reasons for that. The metaphor uses an intuitive concept—who doesn’t know financial debt? It also offers the possibility to think of software quality in a way that sounds objective and quantifiable—definitely less subjective than something like “code smells”—which appeals to our analytical brains.

Actually, this is a common critique of the tech debt metaphor: that tech debt is far from being as quantifiable as it’s purported to be. In this post, I’ll prove otherwise, showing you how you can measure technical debt in practical ways. However, before getting there, it’s important to convince you that technical debt metrics are worth your time. So, I’ll do just that.

I’ll start with a brief definition of the term, with a link to a more in-depth definition in case you need it. Then I’ll cover the reasons why you should care about measuring technical debt. Finally, I’ll walk you through the metrics you should track and how to do it.

Let’s get started.

## Table of Contents

* [What Is Technical Debt?](#what-is-technical-debt)
* [Why Should You Measure Technical Debt?](#why-should-you-measure-technical-debt)
* [Measuring Technical Debt: Identify High-Risk Areas](#measuring-technical-debt-identify-high-risk-areas)
  * [Keep Track of Complexity](#keep-track-of-complexity)
  * [Track Rework Ratio](#track-rework-ratio)
  * [Quantify Your Testing Efforts](#quantify-your-testing-efforts)
  * [Calculate Risk and Add Importance to the Mix](#calculate-risk-and-add-importance-to-the-mix)
* [Software Quality: To Measure It Is to Improve It!](#software-quality-to-measure-it-is-to-improve-it)

![In a nutshell, technical debt means consciously picking an easier solution over the optimal one.](https://assets.linearb.io/uploads/LinearB-8.png)

## What Is Technical Debt?

We do have [a more in-depth exploration](https://linearb.io/blog/handling-technical-debt-in-scrum/) of the concept of technical debt. If you don’t have time to review it now, I’ll treat you to the short version here.

Technical debt is a [metaphor](https://www.agilealliance.org/wp-content/uploads/2016/05/IntroductiontotheTechnicalDebtConcept-V-02.pdf) proposed by Ward Cunningham. In a nutshell, it means consciously picking an easier solution over the optimal one in order to gain time. 

In the metaphor, paying off the debt refers to changing the design to the correct, optimal solution. If you don’t do it, you’ll have to pay interest, which takes the form of additional work in the future due to maintenance difficulties introduced by the “shortcut” you took.

## Why Should You Measure Technical Debt?

If you subscribe to the technical debt metaphor, you probably consider it to be a problem and want to solve it. Great! How would you go about that?

There are a plethora of practices you can use to keep technical debt at bay: automated testing, code reviews, and [refactoring](https://linearb.io/blog/refactoring-in-agile/), just to name a few. However, I believe that before you start tackling technical debt you should measure it. Why?

Solving technical debt can be quite a time-consuming and expensive endeavor. Adding unit tests to a legacy codebase, for instance, is incredibly hard. Remember that professional software development is always an economical enterprise, and as such, decisions must make financial sense.

Here are a few reasons to measure technical debt:

* **It allows you to assess the financial viability of the endeavor.** Maybe a portion of the code is in bad shape, but it’s not a critical area and it doesn’t suffer a lot of changes, so improving it doesn’t make sense.
* **It can help you find an easier solution.** You might find that your bad “scores” are caused by a subsystem that will soon be decommissioned. So, fixing it doesn’t make sense since you’ll soon throw it away.
* **It can help you identify low-hanging fruit.** You might discover portions of the codebase that are relatively easy to fix, allowing you to score some early wins right away.

To sum it up, you should measure technical debt before you set out to fix it because doing that will help you save money. You might even find out that your technical debt isn’t as bad as you previously thought and decide that it’s actually a good idea, economically speaking, to not fix it.

## Measuring Technical Debt: Identify High-Risk Areas

Measuring technical debt is mainly a matter of identifying some [key metrics](https://linearb.io/blog/6-free-technical-debt-metrics-for-your-team/) that, together, can offer you a big-picture view of your work. You need to be able to detect which portions of your codebase offer the higher risk so you can take a risk-based approach and make the most economical decisions.

![Complexity in code can take many forms, but the most straightforward metric for you to track is cyclomatic complexity.](https://assets.linearb.io/uploads/LinearB-9.png)

### Keep Track of Complexity

One of your first steps when trying to identify high-risk areas should be tracking complexity. [Complexity in code](https://linearb.io/blog/what-is-code-complexity/) can take many forms, but the most straightforward metric for you to track is [cyclomatic complexity.](https://linearb.io/blog/cyclomatic-complexity/) In a nutshell, cyclomatic complexity is a measure of how many logical branches there are inside a given function or method.

Cyclomatic complexity correlates with the minimum number of test cases you need to achieve full [branch coverage](https://linearb.io/blog/what-is-branch-coverage/) of a function. Code with lower cyclomatic complexity is typically easier to understand and maintain, which means [reducing cyclomatic complexity](https://linearb.io/blog/reduce-cyclomatic-complexity/) contributes to decreasing the overall [cognitive load](https://linearb.io/blog/cognitive-complexity-in-software/) of a given piece of code.

### Track Rework Ratio

Engineers are more likely to introduce defects to the areas of the codebase they change most often. Also, the fact that a given piece of code suffers too many changes is in itself a warning sign. That might be due to lack of knowledge or experience, poor code review practices, or even requirements being poorly communicated to the engineer.

This metric is called churn, or the rework ratio, and you should track it and strive to keep it low. A high rework ratio is a sign things aren’t quite right and also a potential cause of further problems. Code with a high proportion of rework has a higher risk of introducing bugs into production. LinearB will alert you to high-risk code so that you prevent system outages. 

[![Laugh in the face of danger with high risk work detection. Schedule a demo of WorkerB.](https://assets.linearb.io/uploads/High-risk-Work-1-1024x497.png)](https://linearb.io/demo)

Want to eliminate risky behavior around your PRs? [Book a demo of LinearB today.](https://linearb.io/demo/)

![Not having a comprehensive suite of automated testespecially unit testsis a terrible sign for a codebase when it comes to technical debt.](https://assets.linearb.io/uploads/LinearB-10.png)

### Quantify Your Testing Efforts

Software testing is another investment you need to quantify. Not having a comprehensive suite of automated tests—especially unit tests—is a terrible sign for a codebase when it comes to technical debt. Without tests, engineers aren’t confident to make changes—such as refactoring—that benefit the health of the codebase because they fear breaking things. When that’s the case, the overall quality of the code rapidly decays.

One of the most common forms of quantifying testing efforts is tracking code coverage. There are different [types of code coverage,](https://linearb.io/blog/code-coverage-types/) among which I consider to be the most useful.

Coverage is a funny metric since a low value is certainly a warning sign, but a high value doesn’t necessarily make you rest easy—because _coverage doesn’t tell you anything about the quality of your current test suite_. However, it’s certainly useful to define a threshold—for instance, 80%—and consider everything below that a high-risk area.

### Calculate Risk and Add Importance to the Mix

With the previous metrics—especially the rework ratio—you’ll be able to understand the risk of a given part of the codebase. For instance, a piece of code with a high rework ratio, low code coverage, and high code complexity is certainly high risk. To learn even more about how you can leverage data to manage risk in software, check out [this post](https://linearb.io/blog/risk-management-in-software-engineering/). 

However, parts of a codebase don’t differ only regarding risk. They also vary in how important or critical they are.

If you had the budget to fix only one module in your app, which one you would choose?

* A medium-risk module with code that’s critical for your company
* A high-risk module comprised of utility functions

I think the answer is quite obvious. Additionally, if your codebase contains too much noncritical code, consider extracting this code to external packages. That way, you can improve the signal-to-noise ratio when measuring technical debt in the codebase. In addition, you promote the reuse of code inside your organization.

## Software Quality: To Measure It Is to Improve It!

Technical debt—and code quality as a whole—doesn’t have to be a fuzzy, subjective concept. On the contrary, you can and should [measure it](https://linearb.io/blog/software-quality/). That’s vital if you want to have a chance at fighting and defeating [code rot.](https://linearb.io/blog/what-is-code-rot/)

Most importantly, by quantifying code quality with metrics, you’ll be able to make informed decisions that make economical sense. Sometimes you shouldn’t improve a given piece of code. I know that sounds awful. It hurts me even typing it! 

But remember that there’s an economic imperative behind our work as software engineers. Measuring technical debt helps us decide when to tackle it and when to leave it alone.

With LinearB, you can manage technical debt, as well as other key dimensions of software development like engineering efficiency and code quality. With tools like data dashboards and our WorkerB automation bot, you’ll be able to drive improvement in your development teams so that you ship better code faster. 

[![Improve your engineering organization at every level with LinearB](https://assets.linearb.io/uploads/GenericLineaRB3Pillars-1024x497.png)](https://linearb.io/get-started/)

Want to improve your engineering processes at every level? [Get started with a LinearB free-forever account today!](https://linearb.io/get-started/)

## Improve developer productivity with LinearB

Find us on

[](https://www.linkedin.com/company/linearb)
[](https://devinterrupted.substack.com/)

## Your next read

[![Cover image for AI ROI comes from measuring engineering outcomes on day one](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_AI_ROI_comes_from_measuring_engineering_software_security_2400x1256_2c5eae0862?_a=BAVMn6ID0)](https://linearb.io/blog/kraken-nik-sudan-measure-ai-roi-engineering-outcomes)

Eng. Metrics

[AI ROI comes from measuring engineering outcomes on day one](https://linearb.io/blog/kraken-nik-sudan-measure-ai-roi-engineering-outcomes)

Kraken Engineering Operations Lead Nik Sudan details how to establish day-one data infrastructure to accurately measure AI ROI. Discover why raw token adoption...

[![Cover image for AI is rebuilding software delivery from SDLC to ADLC](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_AI_rebuilding_software_delivery_2400x1256_3fd5887e75?_a=BAVMn6ID0)](https://linearb.io/blog/sdlc-to-adlc-agentic-software-delivery-transformation)

Eng. Metrics

[AI is rebuilding software delivery from SDLC to ADLC](https://linearb.io/blog/sdlc-to-adlc-agentic-software-delivery-transformation)

Discover how engineering organizations are transitioning from the traditional SDLC to an Agentic Development Lifecycle (ADLC). Learn why rising token costs...

[![Cover image for 8 million pull requests reveal where engineering productivity breaks down](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_8_million_pull_requests_2400x1256_03724bfbb2?_a=BAVMn6ID0)](https://linearb.io/blog/8-million-prs-engineering-productivity)

Eng. Metrics

[8 million pull requests reveal where engineering productivity breaks down](https://linearb.io/blog/8-million-prs-engineering-productivity)

8.1M pull requests reveal the gap between AI adoption and engineering impact, and why code review is the bottleneck blocking real productivity gains.

## Structured data

_Machine-readable metadata (JSON-LD) embedded in the page for search/AI context — not content rendered on the page itself._

```json
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "LinearB",
  "url": "https://linearb.io",
  "logo": "https://assets.linearb.io/image/upload/v1715628027/logo-mark-lg.svg",
  "description": "LinearB is the engineering productivity platform that helps engineering leaders prove AI is improving throughput without sacrificing delivery confidence, flow efficiency, or developer experience.",
  "sameAs": [
    "https://www.linkedin.com/company/linearb"
  ],
  "award": [
    {
      "@type": "Award",
      "name": "LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms",
      "dateAwarded": "2026",
      "awardedBy": {
        "@type": "Organization",
        "name": "Gartner®"
      }
    },
    {
      "@type": "Award",
      "name": "Great Place to Work Certification",
      "dateAwarded": "2025-2027",
      "awardedBy": {
        "@type": "Organization",
        "name": "Great Place to Work"
      }
    },
    {
      "@type": "Award",
      "name": "America's Best Startup Employers 2025",
      "dateAwarded": "2025",
      "awardedBy": {
        "@type": "Organization",
        "name": "Forbes Magazine"
      }
    }
  ],
  "hasCertification": [
    {
      "@type": "Certification",
      "name": "SOC 1 Type 2"
    },
    {
      "@type": "Certification",
      "name": "SOC 2 Type 2"
    },
    {
      "@type": "Certification",
      "name": "GDPR Compliance certification"
    },
    {
      "@type": "Certification",
      "name": "ISO 27001"
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Measure Technical Debt Before You Start Tackling It",
  "url": "https://linearb.io/blog/how-to-measure-technical-debt",
  "author": {
    "@type": "Person",
    "name": "Carlos Schults"
  },
  "datePublished": "2022-03-18T09:30:00.000Z",
  "dateModified": "2022-03-18T09:30:00.000Z",
  "image": "https://assets.linearb.io/image/upload/v1720000000/fleur_d_Qf7_R_Zh_MOJU_unsplash_scaled_3bc4861919.jpg",
  "publisher": {
    "@type": "Organization",
    "name": "LinearB",
    "logo": "https://assets.linearb.io/image/upload/v1777485755/linearb-logo-2026.png"
  },
  "description": "Learning how to measure technical debt will allow you to make sound decisions when thinking about software quality. Learn how in this post.\n"
}
```

## More on linearb.io

### Top navigation

- [Book a Demo](https://linearb.io/book-a-demo)
- [AI Code Reviews — Catch security risks, bugs, and spec mismatches](https://linearb.io/platform/ai-code-reviews)
- [AI & Productivity Insights — See how AI tools affect cycle time and delivery speed](https://linearb.io/platform/ai-developer-productivity-insights)
- [Measure AI Impact — Track AI adoption and tie it to delivery outcomes](https://linearb.io/use-case/measure-ai-impact)
- [MCP Server — Chat with your data to spot patterns and boost output](https://linearb.io/platform/mcp-server)
- [Resource Allocation — Cost initiatives and shape your investment strategy](https://linearb.io/platform/resource-allocation)
- [Cost Capitalization — Capitalize engineering costs with audit-ready reports](https://linearb.io/platform/cost-capitalization)
- [Dev Team Management — Set targets and tie throughput to business outcomes](https://linearb.io/platform/goals-and-reporting)
- [DevOps Workflow Automation — Policy-based PR routing, approvals, and tests](https://linearb.io/platform/ai-workflow-governance)
- [AI Powered Support — Unify AI and human code delivery in one clear view](https://linearb.io/use-case/ai-powered-support)
- [Optimization — Surface friction with feedback and MCP insights](https://linearb.io/platform/developer-experience)
- [Reporting — Spot what's working and what needs attention](https://linearb.io/use-case/measuring-developer-experience)
- [Surveys — Turn developer feedback into actionable signals](https://linearb.io/platform/developer-surveys)
- [Platform overview](https://linearb.io/platform/overview)
- [Register now](https://linearb.io/event/engineering-productivity-gap)
- [Customers](https://linearb.io/customers)
- [Pricing](https://linearb.io/pricing)
- [Why choose LinearB — Explore your data. Measure performance. Act to improve it.](https://linearb.io/why-linearb)
- [APEX framework — The operating model for AI-era engineering teams](https://linearb.io/resources/apex-framework)
- [Anti-FAQ — The questions other vendors won't answer](https://linearb.io/why-linearb/anti-faq)
- [Security — Enterprise-grade compliance and zero code access](https://linearb.io/security)
- [Build vs. buy — The hidden cost of building it yourself](https://linearb.io/resources/build-vs-buy)
- [Dev Interrupted Podcast — Conversations with engineering leaders](https://linearb.io/dev-interrupted/podcasts)
- [Reports & Guides — Deep dives on productivity and delivery](https://linearb.io/resources)
- [Webinars — Expert sessions on productivity and AI](https://linearb.io/resources?category=workshops)
- [Metrics Benchmarks — See how your engineering org stacks up](https://linearb.io/resources/software-engineering-benchmarks-report)
- [Blog — Product updates and practical insights](https://linearb.io/blog)
- [Help Center — Documentation, setup, and support](https://linearb.helpdocs.io)
- [API Docs](https://docs.linearb.io/api-overview)
- [Status](https://www.linearbstatus.com/)
- [Integrations](https://linearb.io/integrations)
- [LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms](https://linearb.io/resources/gartner-magic-quadrant-dpi-platforms-2026)
- [Sign in](https://app.linearb.io/login)
- [Enterprise](https://linearb.io/solutions/enterprise)
- [Contact](https://linearb.io/contact-us)
- [About us](https://linearb.io/about-us)
- [Careers](https://linearb.io/careers)
- [Service agreement](https://linearb.io/services-agreement)
- [Privacy policy](https://linearb.io/privacy-policy)
- [DPA](https://linearb.io/data-processing-agreement)
- [Security FAQ](https://linearb.io/security-faq)
- [Substack](https://devinterrupted.substack.com/)

### Footer

_Additional links from the site footer, not repeated from the top navigation above._

- [GitHub](https://github.com/linear-b)
- [LinkedIn](https://www.linkedin.com/company/linearb)
- [Twitter](https://twitter.com/LinearB_Inc)