Metrics for technical debt management: the basics

Last updated on September 16th, 2018 at 05:13 pm

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. 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.

Foundations for behavior guidance decisions

The objective of technical debt management is support for behavior guidance decisions — decisions that guide the behavior and choices of employees so as to control the volume of technical debt. Although many frameworks exist for supporting behavior guidance decisions, they generally consist of four elements:

Quantifiers

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 burden we want to control.

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 the size of the MPrin in advance of actually retiring that debt. After retirement, we know its value without estimating, because the MPrin is what we spent to complete the retirement.

Measures

A measure is the result of determining the value of a quantifier. For example, we might use a quantifier’s definition to determine 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.

Metrics

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 (actual people) 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 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 business objectives.

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.

Dimensions of measure vs. dimensions of metrics

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 advancing project delivery. Thus, we would expect to see small time delays associated with increased incremental technical debt. In other words, all projects of similar scale should lie along the same hyperbola in a plot of this metric in a space in which one axis is debt and the other is the number of days after the target date that the project was delivered.

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 a future post I’ll describe the properties of metrics that are needed for technical debt management.

Contact me on social media:

Reference posts

A collection of definitions of terms as we use them in this blog, with links to longer discussions of each term. Along with each definition is a link to a post that discusses that term in more detail. Read more…

Welcome to Technical Debt for Policymakers. What you’ll find here are resources, insights, and conversations of interest to policymakers who are concerned with managing technical debt within their organizations. Read more…

When retiring one kind of technical debt from an asset, auxiliary technical debt is any other kind of technical debt in the asset. It can be tempting to try to retire auxiliary technical debt too. Sometimes that’s wise, but it can lead to scope creep. Rules of engagement can control this temptation. [More]

To retire technical debt, we need to know where it is. And if service disruptions are necessary, we need to know who will be affected. Here’s a survey of some of the issues, and suggestions for resolving them. [More]

For some assets, we can’t allow debt to persist, and we can’t afford replacements. We must retire the debt. This post begins exploring what it takes to design projects to retire technical debt in irreplaceable assets. [More]

By carefully observing what happens when we actually try to retire some kinds of technical debt, we can better understand the degree of the degree of wickedness of the effort. That understanding helps manage risk in technical debt retirement projects, reducing costs and speeding execution. [More]