Metrics for technical debt management: the basics

Whether it is wise to use metrics for technical debt management is an open question. But whether it will become a widespread practice does seem to be a settled question. Using metrics for technical debt management now does appear to be inevitable. So let’s explore just what we mean by “metrics,” and what traps might lie ahead when we use them for technical debt management.

Measuring tools needed to follow a recipe in the kitchen
Measuring tools needed to follow a recipe in the kitchen. The word “measurement” evokes images that relate to our earliest understanding of the word as children. For most of us, that involves determining the attributes of a physical thing. In most cases, the physical thing of most concern is our own body — its height and weight. But we also measure everyday things, as when following recipes. So the strongest associations with the word “measurement” involve physical things. “Measuring” attributes of an abstract construct like technical debt can be perilous, unless we make allowances for its lack of physicality.

Skepticism about the effectiveness of using metrics for technical debt management is reasonable, because technical debt isn’t a physically measurable thing. “Measuring” technical debt is therefor susceptible to what psychologists call the reification error [Levy 2009] or what philosophers call the Fallacy of Misplaced Concreteness [Whitehead 1948].

The logical fallacy of reification occurs when we treat an abstract construct as if it were a concrete thing. Although reification can provide helpful mental shorthand, it can produce costly cognitive errors. For example, advising someone who’s depressed to get more self-esteem is unlikely to work, because self-esteem isn’t something one can order from Amazon, or anywhere else. One can enhance self-esteem through counseling, reflection, or many other means, but it isn’t a concrete object one can “get.” Self-esteem is an abstract construct.

Technical debt is likewise an abstract construct. We can discuss “measuring” it, but attempts to specify measurement procedures will eventually confront the inherently abstract nature of technical debt, leading to debates about both definitions and the measurement process.

Metrics inherently require some kind of measurement. That’s why skepticism about using metrics for technical debt management is a reasonable position. Reasonable or not, though, metrics will be used. We’d best be prepared to use them responsibly. That’s the focus of this post — and a few to come. If we use metrics for technical debt management, how can we do it responsibly? How can we manage the risks of reification?

This post is about metrics in general. In coming posts I’ll apply this line of thinking to specific examples of metrics for managing technical debt, and suggest approaches that could mitigate reification risk.

Elements of behavior guidance decisions

The objective of technical debt management is support for behavior guidance decisions — decisions that guide the behavior and decisions of employees so as to control the volume of technical debt. The systems we devise for producing the data that supports behavior guidance decisions consist of four elements:


A quantifier is a specification for a measurement process designed to yield a numeric representation of some attribute of an asset or process. With respect to technical debt, we use quantifiers to prescribe how we produce data that represents the state of technical debt of an asset. We also use quantifiers to generate data that captures other related items, such as budgets, the cost or availability of human effort, revenue flows — almost anything that interacts with the assets whose debt we want to describe.

An example of a quantifier is the process for estimating the MPrin of a particular kind of technical debt borne by an asset. The MPrin quantifier definition includes an explicit procedure for measuring it — that is, for estimating its value in advance of retirement. After retirement, we know its value without estimating, because the MPrin is what we spent to complete the retirement.


A measure is the result of determining the value of a quantifier. For example, we might use the quantifier’s definition to determine a measure of how much human effort has been expended on an asset in the past fiscal quarter. Or we might use another quantifier’s definition to determine the current size of the MPrin carried by the asset.


A metric is an arithmetic formula expressed in terms of constants and a set of measures. One of the simpler metrics consists of a single ratio of two measures. For example, the metric that captures the average cost of acquiring a new customer in the previous fiscal quarter is the ratio of two measures, namely, the investment made in acquiring new customers, and the number of new customers acquired.

Associated with some metrics is a defined set of actors who are authorized to take steps — or who are authorized to direct others to take steps — designed to affect the value of the metric in some desirable way. Metrics that have defined sets of actors are usually Key Performance Indicators (see below). If more than one individual is a designated actor for a metric, a process is defined to resolve differences among the designated actors about what action to take, if any. In some cases, this process is as simple as determining which designated actor has the highest organizational rank.

An example of a technical debt metric is the ratio MPrin(i)/MPrin(r) = the total of incremental technical debt (MPrin(i)) incurred in the given time period divided by the total of MPrin retired (MPrin(r)) in that same time period. In periods during which this ratio exceeds 1.0, the organization is accumulating incremental technical debt faster than it is retiring technical debt. Computing it as a ratio, as opposed to a difference, has the effect of expressing the increases (or decreases) in technical debt portfolio size in units of the size of the debt retired. This enables the organization to take on some incremental technical debt responsibly.

This metric also has the virtue of displaying meaningful trends in an easily recognized way. In this case, a steady upward trend means a steadily increasing debt portfolio, even if in some time periods the debt doesn’t increase by much. In other words, the ratio removes some of the “choppiness” that might plague a metric expressed in terms of absolute values.

Key Performance Indicators

A Key Performance Indicator (KPI) is a metric that provides meaningful insight that’s used to guide business decisions. All KPIs are metrics; not all metrics are KPIs.

A KPI is derived from one or more metrics. It represents how successful the business is in accomplishing a given business objective.  A metric, on the other hand, represents only the degree of success in reaching a targeted value for that metric. Because the relationship between the target value of a metric and any given business objective can be complicated, and potentially involve other metrics, metrics that aren’t KPIs are of less value in indicating the degree of success in achieving that business objective.

MPrin(i)/MPrin(r) is a metric that could also serve as a KPI, if the business objective is to achieve steady declines in overall technical debt.

Units of measure vs. units of metrics for technical debt management

Some metrics, such as MPrin(i)/MPrin(r), are dimensionless. Their values are pure numbers. And some metrics have dimensions — units of measure. For example, consider the metric MPrin(i)*Tdelay, where MPrin(i) is the volume of incremental technical debt borne by the deliverable, and Tdelay is the number of days after the target date that the project was delivered. The dimension of this metric is Currency*Days. This metric is particularly interesting, because a common assertion about technical debt is that we incur it as a means of advancing project delivery. Because the evidence for this assertion is mostly anecdotal, actually determining the value of this metric over a number of projects might reveal useful information about the effectiveness of the strategy of incurring technical debt as a means of speeding delivery.

Units of measures are often different from the units of the metrics that those measures support. For example, measures of technical debt in code include test coverage, documentation asynchrony, documentation omissions, code duplication, code complexity, dependency cycles, rule violations, or interface violations. The units of these measures are all different.

To those who must make strategic technical debt management decisions by comparing the costs of retiring different kinds of debt, these detailed measures are awkward to use. MPrin is more directly related to the issues they must address. MPrin provides a unit of comparison among debt retirement options, and between retirement options and available resources. Beyond the level of the particular debt being considered for retirement, MPrin is the dimension of greatest utility. [Brown 2010]

In my next post I’ll describe the properties of metrics that are needed for technical debt management.


[Brown 2010] Nanette Brown, Yuanfang Cai, Yuepu Guo, Rick Kazman, Miryung Kim, Philippe Kruchten, Erin Lim, Alan MacCormack, Robert Nord, Ipek Ozkaya, Raghvinder Sangwan, Carolyn Seaman, Kevin Sullivan, and Nico Zazworka. “Managing Technical Debt in Software-Reliant Systems,” in Proceedings of the FSE/SDP Workshop on Future of Software Engineering Research 2010, New York: ACM, 2010, 47-51.

Available: here; Retrieved: July 30, 2018

Cited in:

[Levy 2009] David A. Levy, Tools of Critical Thinking: Metathoughts for Psychology (second edition). Long Grove, Illinois: Waveland Press, Inc., 2009.

Cited in:

[Whitehead 1948] Alfred North Whitehead. Science and the Modern World. New York: Pelican Mentor (MacMillan), 1948 [1925].

Cited in:

Other posts in this thread

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.