Credit cards. Revolving unsecured charge accounts are perhaps the most familiar form of financial debt. They do have one thing in common with technical debt: with either one, getting into debt over your head is easy.
Second only to the term debt, the term interest is perhaps the most common financial term in the technical debt literature. In the financial realm, interest charges are the cost of using money. Usually, we express interest charges as a percentage rate per unit time. By contrast, metaphorical interest charges (MICs) on technical debt work differently. Failure to fully appreciate that difference can create problems for organizations as they try to manage their technical debt.
The notion of interest is deep in our culture. We understand it well. But the way we understand it corresponds to fixed or slowly varying interest rates. This understanding biases our perception of technical debt.
The root of the problem
Because we’re so familiar with financial interest, we perceive the elements of technical debt as imposing a cost that’s a relatively stable fraction, per fiscal period, of the initial MPrin. This belief doesn’t correspond to the reality of technology-based systems, which are the targets of the technical debt metaphor.
MICs on technical debt differ from the interest on financial debt in two ways.
MICs depend strongly on whether and how the people of the enterprise interact with the assets bearing the technical debt.
The MICs on technical debt include the value of opportunities lost (opportunity costs). These losses are due to depressed productivity and reduced organizational agility.
Neither of these factors has a financial analog. In finance, interest charges depend solely on a mathematical formula involving the interest rate and principal.
Last words
In the next few posts, I’ll explore the properties of metaphorical interest charges. This investigation helps clarify how they differ from financial interest charges. It also clarifies how that difference contributes to difficulties in managing technical debt.
The Principal Principle is that a focus on the metaphorical principal of a technical debt can be your undoing. Focus on the metaphorical interest charges. Drive them to Zero and keep them there.
Misunderstandings about the metaphorical interest charges on technical debt are costly. They prevent us from exploiting the properties of technical debt that reduce carrying costs and retirement costs. And the misunderstandings arise from the fact that the technical debt metaphor is only a metaphor—technical debt and financial debt are different.
The metaphorical interest charges (MICs) and metaphorical principal (MPrin) of a particular class of technical debt can change as a result of retiring other seemingly unrelated classes of technical debt. In most cases, engineering expertise is required to determine technical debt retirement strategies that can exploit this property of technical debt.
Unlike financial debt, for technical debt there are no legally required reports or disclosures. We can sometimes estimate MICs, but most organizations don’t track the data necessary to estimate MICs with useful precision. Indeed, developing useful estimates is often technically impossible.
Rescheduling interest payments on financial debt is possible only by prearrangement or in bankruptcy, but MICs on technical debt can often be rescheduled by rescheduling work that might incur them. This is useful when we plan to retire assets bearing technical debt, because their technical debt vanishes.
Shown here are servers like the ones that made this page available to you. Cybersecurity is concerned with defending servers like these, among others.
Policymakers have in mind the best interests of the entire enterprise. They need a definition of technical debt that’s neutral relative to its causes and manifestations. Defining technical debt in terms of what caused it or where it lies in the enterprise could compromise that necessary neutrality.
That neutrality is important because it enables us to recognize technical debt in whatever form it takes. For example, suppose enterprise policy assumes that technical debt lies only in software. And suppose that the root causes of some instances of technical debt are new threats in the cybersecurity environment that render obsolete our cyberdefenses. 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.
A definition that’s useful for guiding policy
Here’s a cause-neutral and manifestation-neutral definition of technical debt. It’s 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. It is therefore something we would 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. These ideas are analogous 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
An important extension beyond conventional definitions
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 is one due to Ken Pugh, who defines acceptance test debt as “…the nonexistence or nonautomation of acceptance tests.” [Pugh 2010] If we want to include all sources of reduced organizational agility or unnecessary operating expense arising from technical debt, our definition must also address non-existence issues like those Pugh has identified.
The definition above is workable for systems of all kinds. Consider two examples of “hardware”:
But the definition also applies to anything that takes a technological form, 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.
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.
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.
