A policymaker’s definition of technical debt

Last updated on January 20th, 2019 at 01:54 pm

Policymakers have in mind the best interests of the entire enterprise. They need a definition of technical debt that is neutral relative to its causes and manifestations, because defining technical debt in terms of what caused it or where it lies in the enterprise could compromise that necessary neutrality.

For example, if enterprise policy assumes that technical debt is something that lies only in software, and if the root causes of some instances of technical debt are new and developing threats in the cybersecurity environment, then enterprise policy vis-à-vis technical debt is likely to be ineffective. It might lead to decision makers focusing too much attention on the software development process and too little attention on the cybersecurity and threat intelligence processes.

Here’s a cause-neutral and manifestation-neutral definition of technical debt, what I call the policymaker’s definition [Brenner 2017a]:

Technical debt is any technological element that contributes, through its existence or through its absence, to lower productivity or to a higher probability of defects during development, maintenance, or enhancement efforts, or which depresses velocity in some other way, and which we would therefore like to revise, repair, replace, rewrite, create, or re-engineer for sound engineering reasons. It can be found in—or it can be missing from—software, hardware, processes, procedures, practices, or any associated artifact, acquired by the enterprise or created within it.

Extending the technical debt metaphor just a bit, people often talk about the principal and the interest charges associated with a technical debt, by analogy to the principal and interest charges associated with a financial debt. They’re convenient concepts, but the parallels between finance and technology aren’t real, and that’s where the trouble lies. Read more

There’s one other generalization contained in this definition of technical debt that differs from most other definitions. It’s in the phrase “or missing from.” Our policymaker’s definition doesn’t require that the technical debt item actually exist. That is, the absence of something can constitute technical debt. My favorite example of this was put forward by Ken Pugh, who defines acceptance test debt as “…the nonexistence or nonautomation of acceptance tests.” [Pugh 2010] If we seek to encompass all sources of reduced organizational responsiveness or unnecessary operating expense arising from technical debt, the definition of technical debt that we require must also address non-existence issues such as those identified by Pugh.

The definition above is workable for systems of all kinds. Consider two examples of “hardware”:

• Technical debt in a rail system
• Technical debt in the highway system

But the definition also applies to anything that is manifested in technological forms, including business plans, legislation, procedures, and microprocessor designs—almost anything.

References

[Brenner 2017a] Richard Brenner. “A Policy Maker’s Definition of Technical Debt,” Cutter Consortium Executive Update, February 27, 2017.

• A policymaker’s definition of technical debt

[Pugh 2010] Ken Pugh. “The Risks of Acceptance Test Debt,” Cutter Business Technology Journal, October 2010, 25-29.

• A policymaker’s definition of technical debt
• Debt contagion: how technical debt can create more technical debt

Related posts

• Who are the policymakers?
  As I use the term in this blog, a policymaker is someone who is responsible for developing, revising, or approving organizational policies that affect technical debt management.
• What is policy?
  Policy is one of those concepts that we rarely define explicitly because we believe we all agree on what it means. But in this context, we must take some care to be certain that we do in fact agree. In this blog, policy is the set of general guidelines people follow when making decisions and taking action.