How MPrin can change spontaneously

Last updated on July 7th, 2021 at 10:53 am

Recall that our definition of the metaphorical principal of a technical debt (MPrin) at a given time is the cost of retiring the debt at that time. This cost can change with time. For example, due to ongoing maintenance and enhancements, the part of the asset in which the debt is embedded might become rather more complicated or constrained than it was earlier. That increased complexity can increase MPrin. This can happen even if the elements that comprise the debt itself have remained unchanged.

Moreover, the MPrin of any extensions to the asset in question, or to other assets, might also change. Those assets that use services provided by a subsystem manifesting the debt might also require alteration at debt retirement time. Untangling the debt from its surroundings, making necessary modifications, and testing the result, can be a delicate and complex process. The process might actually cost more at debt retirement time than whatever was saved when the debt was incurred.

An example of MPrin changing spontaneously

On the other hand, in some circumstances, the cost of retiring the debt can decrease over time. Consider the following fictitious example.

A high pressure sodium streetlight at dusk
A high pressure sodium streetlight at dusk. Photo (cc) Famartin courtesy Wikimedia Commons.

Zion is a small city of 110,000 that’s struggling with two problems related to street lighting. Its current streetlights use High-Pressure Sodium (HPS) lights. HPS lights use almost twice as much energy as do the newer LED streetlights for the same level of illumination. Zion’s second problem is that the existing streetlights provide only one level of illumination throughout the city. This is causing a stream of complaints from many residents who have concerns about street lighting spilling onto their property at night. The bright light interferes with the sleep patterns of people and their pets.

Both of these problems have technical solutions that became available after the current HPS lights were installed. That’s why we can view them as arising from technical debt. Zion had investigated resolving the light pollution problem, but couldn’t find an affordable solution. Time passed. When LED streetlights became widely available, Zion investigated retiring its HPS lights. They found an LED lighting system that was dimmable on a block-by-block basis using a wireless control system. By retiring the technical debt associated with the HPS lights, Zion was able to afford retiring the technical debt associated with its un-dimmable lighting system.

Zion was able to afford to retire both forms of technical debt at once because of the way they interacted, even though retiring them one at a time would have been too expensive.

This example shows that the MPrin of a technical debt can vary widely, depending on the assets involved, and on what other debts they carry. Such variation is far more common in the realm of technical debt than it is in the world of financial debt.

Related posts

The metaphorical principal of a technical debt

Last updated on July 8th, 2021 at 11:47 am

The “metaphorical principal” amount of a technical debt isn’t like the principal amount of a financial debt. In fact, the two are so different that policymakers can make real trouble for their organizations if they fail to take the differences into account.

Accomac Debtors’ Prison in Accomac, Virginia
Accomac Debtors’ Prison in Accomac, Virginia. After construction in 1783 it served as a jailer’s house. It served as a debtors’ prison from 1824 to 1849. Debtors could regain freedom by working to earn their keep and retire their debts, if they couldn’t pay them off. Today, bankruptcy laws facilitate property seizures to retire debts. Requiring an organization’s engineering functions to fund technical debt retirement through expense budgets is analogous to debtors’ prison. Photo (cc) Ser Amantio di Nicolao, courtesy Wikimedia Commons.
In finance, the principal amount of a loan at the time of origination is the amount the creditor transfers to the debtor. Over time, as the debtor makes payments according to the terms of the loan agreement, the principal either remains constant or declines gradually. The terms of the loan agreement determine the actual remaining principal at any given time. This is the layperson’s definition. It’s the basis of the association people make with respect to the metaphorical principal amount of a technical debt.

Consequences of the layperson’s definition of debt

For technical debt management, the associations most people make with the debt concept are unfortunate. For example, using the term principal to refer to the metaphorical principal of a technical debt creates risk. The risk arises because the metaphorical principal behaves very differently from financial principal. Financial principal is typically constant or slowly declining. The metaphorical principal of technical debt can exhibit sudden and dramatic fluctuations. These confusions arise because of unintended associations of the technical debt metaphor.

Why I use the term MPrin instead of principal

We need a way to limit the risk of confusing the metaphorical principal of technical debt with the principal of a financial debt. The term metaphorical principal is so inconvenient that I prefer MPrin.

Most people don’t distinguish the initial principal amount of a technical debt and MPrin. But some have addressed it [Seaman 2013]. For example, Avgeriou et al. define the initial principal of a particular class of technical debt as the savings realized by incurring the debt [Avgeriou 2016]. They define the current principal as the resources required to deploy a different or better solution at the current time.

The initial principal concept of Avgeriou et al. is what I call in this blog the MPrin at the time the debt is incurred, or initial MPrin. Although the initial MPrin does have some value for decision makers at the time the debt is incurred, it’s most valuable when deciding whether to incur the debt, if, indeed, one has an opportunity to make such a decision. However, once the organization incurs the debt, the current MPrin at debt retirement time is what matters; initial MPrin becomes irrelevant.

Last words

Policymakers must keep clearly in mind that the MPrin of a given kind of technical debt is the total cost of retiring that debt, at the time it is retired, including all cost sources.

We’ll have a look at the policy implications of the properties of MPrin next time.

References

[Avgeriou 2016] Paris Avgeriou, Philippe Kruchten, Ipek Ozkaya, and Carolyn Seaman, eds. “Managing Technical Debt in Software Engineering,” Dagstuhl Reports, 6:4, 110–138, 2016.

Available: here; Retrieved: March 10, 2017.

Cited in:

[Seaman 2013] Carolyn Seaman. “Measuring and Monitoring Technical Debt” 27 March 2013. Slides.

Defines technical debt as the gap between just making it work and doing it right. This is the initial principal approach to the definition. Considers known defects not fixed to be technical debt.

Cited in:

Related posts

A policymaker’s definition of technical debt

Last updated on July 18th, 2021 at 03:32 pm

Servers like the ones that made this page available to you. Most servers would benefit from comparison with a policymaker’s definition of technical debt
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

[Avgeriou 2016] Paris Avgeriou, Philippe Kruchten, Ipek Ozkaya, and Carolyn Seaman, eds. “Managing Technical Debt in Software Engineering,” Dagstuhl Reports, 6:4, 110–138, 2016.

Available: here; Retrieved: March 10, 2017.

Cited in:

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

Cited in:

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

Cited in:

[Seaman 2013] Carolyn Seaman. “Measuring and Monitoring Technical Debt” 27 March 2013. Slides.

Defines technical debt as the gap between just making it work and doing it right. This is the initial principal approach to the definition. Considers known defects not fixed to be technical debt.

Cited in:

Related posts

Show Buttons
Hide Buttons