Last updated on November 21st, 2017 at 08:30 am
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:
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”:
But the definition also applies to anything that is manifested in technological forms, including business plans, legislation, procedures, and microprocessor designs — almost anything.