Category: MPrin

Posted on

The Principal Principle: Focus on MICs

Last updated on July 7th, 2021 at 03:16 pm

The door to a bank vault
The door to a bank vault. One way to know that technical debt differs from financial debt is that banks aren’t involved in any way. Treating technical debt as if it had anything in common with financial debt—beyond our own sense of obligation—is a shortcut to real trouble. Remember the Principal Principle.

When some organizations first realize that technical debt is limiting their performance, they begin by chartering a “technical debt inventory.” They try to determine how much technical debt they’re carrying, where it is, and how much retiring it would cost. They really want to know how fast they can retire it. That’s understandable. It’s not too different from how one would approach an out-of-control financial debt situation. It might be understandable, but in most cases, inventorying all technical debt is ineffective. For technical debt we need a different approach, because technical debt is different from financial debt. With technical debt, we must be follow what I call the Principal Principle, which is:

The Metaphorical Principal (MPrin) of a technical debt, which is the cost of retiring it, isn’t what matters most. What usually matters most is the Metaphorical Interest Charges—the MICs.

Why MICs matter more

MICs on technical debt can vary dramatically. For assets that aren’t undergoing maintenance or enhancement, the MICs can be Zero for extended periods. And for retiring assets, any technical debt they carry can vanish when the asset passes out of service. For other assets, MICs can be dramatically higher—beyond the total cost of replacing the asset.

Most people regard the sole effect of MICs as reduction in engineering productivity. I take a different approach. I include in MICs anything associated with technical debt and which depresses net income. That would include lost or delayed revenue, increased expenses—anything. For example, suppose technical debt causes a two-month delay in reaching a market. IN that case, its effect on revenues can be substantial for years to come. I regard all of that total effect as contributing to MICs.

So the Principal Principle is that a focus on Principal can be your undoing. Focus on MICs instead. Drive them to Zero and keep them there.

Other posts in this thread

Posted on

How financial interest charges differ from interest charges on technical debt

Last updated on July 7th, 2021 at 02:55 pm

Credit cards also have interest charges
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.

Related posts

  • The Principal Principle: Focus on MICs
    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.
  • Where the misunderstandings about MICs come from
    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.
  • MICs can change when other debts are retired
    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.
  • MICs on technical debt can be difficult to measure
    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.
  • MICs can sometimes be deferred or advanced without penalty
    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.
Posted on

MPrin for missing or incomplete capability

Last updated on July 7th, 2021 at 02:53 pm

In some instances, the metaphorical principal (MPrin) of a technical debt is a missing or incompletely implemented capability. For example, absence of a fully automated regression test suite can create difficulties for testing a complex system. Defects can slip through. That would result in reduced productivity and velocity. In this case, the projected cost of implementing, testing, and documenting the test suite, and training its users, would constitute the initial MPrin of the outstanding technical debt. This definition differs from some definitions, because it includes testing, documenting, and initial training. In general, from the enterprise perspective, when identifying the MPrin associated with missing or incompletely implemented capabilities, we must include all artifacts necessary to eliminate reductions in productivity and velocity.

But even if we include these items in the conventional definition, MPrin at retirement can exceed the savings at the time we incurred the debt. For example, in the interval between origination and retirement the assets involved can change. Moreover, if retiring the debt causes a revenue stream interruption, the MPrin, which includes the lost revenue, can be significantly larger than the initial MPrin.

Unique problems of incompletely implemented capability

A concrete building under construction
A concrete building under construction. Concrete takes about a month to cure and reach full strength. If we waited for full curing before pouring the floor above, multistory concrete construction would be slow and expensive. So we start on the next floor after only a few days. Because the floors can’t support themselves for about a week, we shore them using lower floors. The shoring constitutes a technical debt resulting from the “incomplete implementation” (partial cure) of each floor. We retire that debt by removing the shoring as we go. More about shoring and re-shoring
Technical debt associated with incompletely implemented capability presents unique problems. We can retire it in three distinct ways. First, we can complete the implementation. The MPrin associated with this approach can grow beyond the initial cost of completion, for the usual reasons. Second, we can cancel the capability. If we do, retiring the debt completely would require removal of all artifacts that we no longer need. Finally, we can choose a middle path. In the middle path we adopt some parts that have been completed. But we reject other parts, and we add whatever is necessary to create a limited version of what we originally planned.

Special challenges of non-physical assets

Invisibility is an important attribute of non-physical assets such as software, procedures, legislation, regulations, and so on. Technical debt associated with incomplete implementation is difficult to manage in such assets. For example, the image above shows several levels of a concrete building under construction. The vertical members between the levels are part of a shoring system that supports the levels of the building. Shoring is necessary until the concrete floors cure well enough to support themselves. Shoring constitutes a kind of technical debt that must be “retired” before the building is complete. The teams constructing the building could never forget to remove the shoring because it obstructs installation of the windows and walls.

But things are very different with non-physical assets. It’s easy to forget to remove intermediate artifacts, or elements that were part of attempts that didn’t work out. Many non-physical assets are perfectly functional carrying that kind of technical debt. That debt becomes evident with time, as the asset becomes increasingly difficult to maintain, extend, or defend.

It’s this property of non-physical assets that makes technical debt management so much more difficult than it is with physical assets. Not more important, just more difficult.

Related posts

  • MPrin when standards or regulations change
    The Metaphorical Principal of a technical debt that’s incurred as a result of a change in standards or regulations, internal or external, is the cost of bringing all affected assets into full compliance. Properly accounted for, however, the MPrin should include ripple effects, which are the changes in other assets that are required to keep them compatible with the assets that are directly affected.
  • MPrin in a platform component upgrade
    Platform component upgrades often trigger the need to make changes in whatever sits atop the platform, to maintain compatibility with the platform. Those changes obviously contribute to MPrin. But less obvious are the contributions that arise from deferring the upgrade.
  • MPrin in a development project
    The MPrin of an asset that is subjected to new development or enhancement has some special characteristics. For an existing asset, new development can lead to duplication of capability. For new assets, unanticipated opportunities can transform into technical debt components that were not viewed as technical debt, without ever changing them in any way.
  • Examples of MPrin in four scenarios
    Some examples might help to clarify the differences between the principal of financial debts and the Metaphorical Principal of a technical debt. The examples to come in the next four posts are designed to illustrate the unique properties of MPrins of technical debts.
  • Useful projections of MPrin might not be attainable
    Expect the unexpected with technical debt retirement efforts, because they can conflict with ongoing operations, maintenance of existing capabilities, development of new capabilities, cyberdefense, or other technical debt retirement efforts. Policymakers can make important contributions to the enterprise mission if they can devise guidelines and frameworks for resolving these conflicts as closely as possible to the technical level.
  • The metaphorical principal of a technical debt
    The principal amount of a financial debt and the metaphorical principal of a technical debt have very different properties. They are so different that it’s wise to avoid using the term “principal” to refer to the metaphorical principal of a technical debt. We use the term MPrin.
Posted on

MPrin when standards or regulations change

Last updated on July 7th, 2021 at 11:15 am

The MPrin of technical debt that forms as a result of a change in standards or regulations is the cost of bringing affected assets into compliance. It matters not whether the standards in question are internal to your organization or external. The conventional definition of the MPrin for this kind of technical debt includes only the cost of aligning to the new standards or regs, the assets directly affected. But the conventional definition is incomplete. If we account for all work properly, the MPrin should also include ripple effects. Ripple effects are the changes in other assets that we must perform to maintain compatibility with the assets affected directly by the change in standards or regs.

The phrase standards or regs is beginning to bother even me. I’ll switch to standards when I mean standards or regulations (or regs) except when I say so explicitly.

Cost drivers of changes in standards

A view of the left side guard on a truck operated by the City of Cambridge, Massachusetts
A view of the left side guard on a truck operated by the City of Cambridge, Massachusetts. Side guards prevent vulnerable road users (pedestrians, bicyclists, and motorcyclists) from being swept under trucks and crushed (and often killed) by the truck’s rear wheels. Cambridge has a pilot program affecting city-operated trucks, but Boston is requiring all contractors to install side guards. This change in regulations creates a technical debt for all truck operators whose vehicles lack side guards. [Volpe 2017] City of Cambridge photo courtesy U.S. Department of Transportation.

Aligning existing assets to new standards can have expensive consequences. We must include all costs in the calculation of MPrin. Unfortunately, some costs are often overlooked or accounted for in other ways. For example, testing might require a service interruption or product availability delays or interruptions. And that could entail a revenue stream delay or interruption. That lost revenue is certainly a consequence of the debt retirement effort.

Deferring retirement of this class of technical debt can expose the enterprise to the risk of MPrin growth in two ways. First, when we defer debt retirement, the number of instances of violations of the new standards can increase as we develop new assets in compliance with the obsolete standards. Second is the potential for increases in the number of ripple effect instances when we defer debt retirement. These instances arise from increases in the number of artifacts that require updating. The issue isn’t that they aren’t compliant with the new standards. Rather, it is that we must align them with the components we modify to comply with the new standards. In this way, MPrin at debt retirement time can greatly exceed the savings we realized when we first incurred the debt.

Last words

However, as with most technical debts, deferring retirement of this class of debt can sometimes be wise. For example, if the assets that bear the debt are about to be retired, the debt they carry vanishes when we retire those assets.

References

[Volpe 2017] Volpe National Transportation Systems Center. “Truck Side Guards Resource Page,” October 2017.

Available: here; Retrieved: November 22, 2017

Cited in:

Related posts

  • MPrin for missing or incomplete capability
    In some instances, technical debt is actually a missing or incompletely implemented capability. If we retire the debt by completing the implementation, the MPrin is the cost of that effort, plus any training, testing, and lost revenue. If we retire the debt by halting or withdrawing the capability, the MPrin is the total cost of removal, plus testing and lost revenue.
  • MPrin in a platform component upgrade
    Platform component upgrades often trigger the need to make changes in whatever sits atop the platform, to maintain compatibility with the platform. Those changes obviously contribute to MPrin. But less obvious are the contributions that arise from deferring the upgrade.
  • MPrin in a development project
    The MPrin of an asset that is subjected to new development or enhancement has some special characteristics. For an existing asset, new development can lead to duplication of capability. For new assets, unanticipated opportunities can transform into technical debt components that were not viewed as technical debt, without ever changing them in any way.
  • Examples of MPrin in four scenarios
    Some examples might help to clarify the differences between the principal of financial debts and the Metaphorical Principal of a technical debt. The examples to come in the next four posts are designed to illustrate the unique properties of MPrins of technical debts.
  • Useful projections of MPrin might not be attainable
    Expect the unexpected with technical debt retirement efforts, because they can conflict with ongoing operations, maintenance of existing capabilities, development of new capabilities, cyberdefense, or other technical debt retirement efforts. Policymakers can make important contributions to the enterprise mission if they can devise guidelines and frameworks for resolving these conflicts as closely as possible to the technical level.
  • The metaphorical principal of a technical debt
    The principal amount of a financial debt and the metaphorical principal of a technical debt have very different properties. They are so different that it’s wise to avoid using the term “principal” to refer to the metaphorical principal of a technical debt. We use the term MPrin.
Posted on

MPrin in a platform component upgrade

Last updated on July 12th, 2021 at 03:05 am

An aisle in the stacks of a library, where marking the books with RFID tags would be a platform component upgrade
An aisle in the stacks of a library. Some libraries are upgrading their book tagging systems from barcodes to RFID tags. This is essentially a platform component upgrade. When they do convert, every item in their collections becomes an instance of technical debt until it’s tagged with an RFID. A tagging technician can process about 1,000 items per day [Boss 2011]. It’s a big job.

The MPrin of technical debt that forms as a consequence of a platform component upgrade depends on how we incur the debt. If we incur the debt by installing the upgrade, and then perform only some of the work made necessary by the upgrade, then the MPrin is the total cost of performing the deferred work. If we incur the debt by deferring the upgrade, then the conventional definition of the MPrin has two components. The first is the cost of the upgrade, and the second is the cost of any work made necessary by the upgrade, but not performed.

Hold on—it’s not so simple

In this latter instance, MPrin can increase over time. Increases can occur if the following three-step sequence happens for either maintenance or enhancements. In step 1, we perform work in the environment of the obsolete platform component, but after deferring the upgrade. Step 2 is performance of the upgrade. In step 3, we must repeat the work we performed in step 1 because the step 1 version isn’t compatible with the upgrade. This situation can be even worse if we discover the need for step 3 as a result of operational failure after the upgrade. In that case, maintainers must investigate the failure first. And the failure might cause database contamination, which would also need remedying. These additional costs are actually part of the debt retirement effort for the debt incurred by deferring the upgrade, but we usually account for them—mistakenly—as routine operational expense.

Last words

Advance knowledge of what can go wrong is always a nice-to-have. Most of us try to acquire this knowledge before or as we plan our projects. And most of us can do better. Before you consider a plan complete, ask yourself if anyone else might have already tried something similar. If you can guess who that might be, contact him or her to find out how it went. No point repeating someone else’s mistakes.

References

[Boss 2011] Richard W. Boss, “RFID Technology for Libraries,” American Library Association, 2011.

Some libraries are upgrading their book tagging systems from barcodes to RFID tags—what is essentially a platform upgrade. When they do convert, every item in their collections becomes an instance of technical debt until it’s tagged with an RFID. A tagging technician can process about 1,000 items per day. It’s a big job. Available: here; Retrieved: November 21, 2017

Cited in:

[Volpe 2017] Volpe National Transportation Systems Center. “Truck Side Guards Resource Page,” October 2017.

Available: here; Retrieved: November 22, 2017

Cited in:

Related posts

  • MPrin for missing or incomplete capability
    In some instances, technical debt is actually a missing or incompletely implemented capability. If we retire the debt by completing the implementation, the MPrin is the cost of that effort, plus any training, testing, and lost revenue. If we retire the debt by halting or withdrawing the capability, the MPrin is the total cost of removal, plus testing and lost revenue.
  • MPrin when standards or regulations change
    The Metaphorical Principal of a technical debt that’s incurred as a result of a change in standards or regulations, internal or external, is the cost of bringing all affected assets into full compliance. Properly accounted for, however, the MPrin should include ripple effects, which are the changes in other assets that are required to keep them compatible with the assets that are directly affected.
  • MPrin in a development project
    The MPrin of an asset that is subjected to new development or enhancement has some special characteristics. For an existing asset, new development can lead to duplication of capability. For new assets, unanticipated opportunities can transform into technical debt components that were not viewed as technical debt, without ever changing them in any way.
  • Examples of MPrin in four scenarios
    Some examples might help to clarify the differences between the principal of financial debts and the Metaphorical Principal of a technical debt. The examples to come in the next four posts are designed to illustrate the unique properties of MPrins of technical debts.
  • Useful projections of MPrin might not be attainable
    Expect the unexpected with technical debt retirement efforts, because they can conflict with ongoing operations, maintenance of existing capabilities, development of new capabilities, cyberdefense, or other technical debt retirement efforts. Policymakers can make important contributions to the enterprise mission if they can devise guidelines and frameworks for resolving these conflicts as closely as possible to the technical level.
  • The metaphorical principal of a technical debt
    The principal amount of a financial debt and the metaphorical principal of a technical debt have very different properties. They are so different that it’s wise to avoid using the term “principal” to refer to the metaphorical principal of a technical debt. We use the term MPrin.
Posted on

MPrin in a development project

Last updated on July 7th, 2021 at 11:12 am

The "basket bridge" of the Los Angeles Metro system
The “basket bridge” of the Los Angeles Metro system. Constructed by the Metro Gold Line Foothill Extension Construction Authority, and opened in 2012, it carries the Los Angeles to Pasadena Metro Gold Line light rail across the eastbound lanes of the I-210 Freeway. The rail line provides transport service to a ridership that had been driving or using bus service. Although the bus and rail aren’t exact duplicates of each other, there is enough overlap that bus ridership dropped significantly after the rail line opened. That drop created a technical debt in the bus system. Retiring that debt requires reducing, rescheduling and re-routing bus service [Broverman 2017].

We usually regard the MPrin of new technical debt associated with a development project as the difference between the cost of implementing it sustainably and the cost of simply making it work. The effort saved by choosing the latter over the former is the initial MPrin of the technical debt.

For example, consider an enhancement project for an existing asset. After we achieve an operational capability, we might notice that we’ve duplicated some of the asset’s pre-existing functionality. The responsible debt-free approach has three stages. First, we eliminate the new and unnecessary duplicated capability. Next, we modify the asset to use the previously existing capability. Finally, we re-test the asset. The approach that generates new debt involves leaving the duplication in place.

Other generators of technical debt

In a closely related example, we might recognize that the duplicated functionality in the newly developed portion of the asset is superior to the pre-existing form elsewhere in the asset. We’d like to remove the pre-existing form and replace instances of that form with instances of the newly developed functionality. But that work is clearly outside the scope of the new development, and it must await budgetary authority before it can be undertaken. Consequently, it becomes technical debt for the larger asset.

As time passes, and the enterprise undertakes other development projects, the implementations of previous projects can accumulate additional technical debt. The more obvious mechanisms by which this occurs include defect discovery, customer requests for enhancements, the need to enhance cyberdefenses in response to new threats, or changes in law or regulation. Less obvious, but no less significant, are changes in markets, customer needs, and underlying technologies. All can contribute to technical debt formation

A final example

An example of a less obvious process might be insights gained in marketing one product (call it P1). Suppose those insights reveal an opportunity to introduce other related products—P2, P3, and P4—to form a suite. The latter products could employ some assets developed for P1, if the latter products had been constructed slightly differently. The changes required in P1 therefore constitute technical debt, because we would have been able to develop P2, P3, and P4 much more rapidly if we had recognized the opportunity earlier. The P1 changes then become technical debt. And if we pursue P2, P3, or P4 without first retiring that debt, the debt probably expands, because the subsequent products manifest it.

New product (or service) developments often generate these situations.

References

[Boss 2011] Richard W. Boss, “RFID Technology for Libraries,” American Library Association, 2011.

Some libraries are upgrading their book tagging systems from barcodes to RFID tags—what is essentially a platform upgrade. When they do convert, every item in their collections becomes an instance of technical debt until it’s tagged with an RFID. A tagging technician can process about 1,000 items per day. It’s a big job. Available: here; Retrieved: November 21, 2017

Cited in:

[Broverman 2017] Neal Broverman. “The Success of the Gold and Expo Lines Has Taken a Toll on Bus Ridership,” Los Angeles Magazine, March 30, 2017.

Available: here; Retrieved: November 21, 2017

Cited in:

[Volpe 2017] Volpe National Transportation Systems Center. “Truck Side Guards Resource Page,” October 2017.

Available: here; Retrieved: November 22, 2017

Cited in:

Related posts

  • MPrin for missing or incomplete capability
    In some instances, technical debt is actually a missing or incompletely implemented capability. If we retire the debt by completing the implementation, the MPrin is the cost of that effort, plus any training, testing, and lost revenue. If we retire the debt by halting or withdrawing the capability, the MPrin is the total cost of removal, plus testing and lost revenue.
  • MPrin when standards or regulations change
    The Metaphorical Principal of a technical debt that’s incurred as a result of a change in standards or regulations, internal or external, is the cost of bringing all affected assets into full compliance. Properly accounted for, however, the MPrin should include ripple effects, which are the changes in other assets that are required to keep them compatible with the assets that are directly affected.
  • MPrin in a platform component upgrade
    Platform component upgrades often trigger the need to make changes in whatever sits atop the platform, to maintain compatibility with the platform. Those changes obviously contribute to MPrin. But less obvious are the contributions that arise from deferring the upgrade.
  • Examples of MPrin in four scenarios
    Some examples might help to clarify the differences between the principal of financial debts and the Metaphorical Principal of a technical debt. The examples to come in the next four posts are designed to illustrate the unique properties of MPrins of technical debts.
  • Useful projections of MPrin might not be attainable
    Expect the unexpected with technical debt retirement efforts, because they can conflict with ongoing operations, maintenance of existing capabilities, development of new capabilities, cyberdefense, or other technical debt retirement efforts. Policymakers can make important contributions to the enterprise mission if they can devise guidelines and frameworks for resolving these conflicts as closely as possible to the technical level.
  • The metaphorical principal of a technical debt
    The principal amount of a financial debt and the metaphorical principal of a technical debt have very different properties. They are so different that it’s wise to avoid using the term “principal” to refer to the metaphorical principal of a technical debt. We use the term MPrin.
Posted on

Examples of MPrin in four scenarios

Last updated on June 15th, 2021 at 01:57 pm

Some examples might help to clarify the differences between the principal of financial debts and the MPrin of a technical debt. The examples to come in the next four posts illustrate the unique properties of MPrins of technical debts.

Technical debt can arise as a result of:
  • Changes internally within the enterprise
  • External environmental changes that directly affect existing assets
  • Changes in the competitive environment
  • Insights and changes in perception that lead to changes in objectives
  • Existing technical debt
  • Deferring decisions about almost anything

By contrast, we incur financial debt only as a result of decisions to incur financial debt.

The examples below illustrate some of these phenomena. For each one, the full post contains a more complete explanation.

Development projects

This example illustrates how technical debt can develop as a result of unanticipated insight regarding a marketing opportunity for a new product line. It shows how technical debt can arise independent of any decision made within the enterprise, and without any changes to assets of any kind. More: “MPrin in a development project”

Platform component upgrades

We’ve already provided an example of technical debt arising from a platform upgrade. In this example, we show how deferring a platform upgrade creates new complications not present in the previous example, by illustrating how total MPrin can increase after the debt first forms. More: “MPrin in a platform component upgrade”

Standards or regulatory changes

Changes in standards or regulations, whether internal, industry-wide, or governmental, can create technical debt. In some cases, the enterprise might not even be aware of the new debt. More: “MPrin when standards or regulations change”

Missing or incompletely implemented capability

When a capability is incompletely implemented, it’s clear that the part left undone constitutes technical debt. What is less clear is what happens when the capability implementation is halted or rescinded. Trying to avoid new technical debt can actually be the cause of new technical debt, albeit of a different kind. More: “MPrin for missing or incomplete capability”

Whether or not any similar scenarios have happened in your organization, these discussions are helpful for gaining insight into what kinds of technical debt policies can assist your organization in managing its technical debt. Let me know if you have experience with situations in which problems can be traced, even if only in part, to treating technical debt as if it were financial debt.

Posted on

Useful projections of MPrin might not be attainable

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

SummaryExpect the unexpected with technical debt retirement efforts. Technical debt retirement efforts can conflict with ongoing operations, maintenance of existing capabilities, development of new capabilities, cyberdefense, or other technical debt retirement efforts. Although these conflicts are technical in nature, resolving them can involve business priorities at any level. Planners must be aware of these potential conflicts, and coordinate with their leaders. Policymakers can make important contributions to the enterprise mission if they can devise guidelines and frameworks for resolving these conflicts as closely as possible to the technical level.

For planning purposes, it’s necessary from time to time to make projections of debt retirement costs (MPrin) for a given class of technical debt. The need arises when planning debt retirement, or when preparing debt retirement options for determining resource allocations. Although retiring some kinds of technical debt is straightforward, other kinds of debt can become intertwined with each other. Retiring still others might appear to be easy, but actual retirement efforts expose unanticipated entanglements. Moreover, debt retirement efforts can sometimes interact with other debt retirement efforts, operations, maintenance, cyberdefense, and new development in both expected and unexpected ways. For these reasons, making estimates of the MPrin with enough precision to be useful can be notoriously difficult.

Money is fungible; people are not

A tangle of cordage
A tangle of cordage on board ship. Different kinds of technical debt can become entangled with each other. Untangling them can affect various other engineering efforts. Preparing an asset for a debt retirement effort by doing some preliminary untangling might be wise before trying to estimate the MPrin of any affected class of technical debt.
These considerations rarely arise when planning retirement of financial debts, because money is fungible. We might indeed have other uses for financial resources. But every unit of cash is equivalent to every other. That freedom isn’t necessarily available when planning resource allocations for technical debt retirement.

For example, not every engineer is equally capable of addressing every problem. Some people are particularly capable for certain kinds of work, and not very capable for other kinds. The problem of scheduling specialists is notorious for generating bottlenecks. And split assignments create even more trouble. People aren’t fungible.

Last words

Planning retirement of a particular set of technical debt classes can be complicated. Such planning requires knowledge of any efforts with which that retirement effort might interact. That information might not be available or might not be known. In general, preliminary work to decouple these activities—often called ”refactoring”—can

Related posts

  • MPrin for missing or incomplete capability
    In some instances, technical debt is actually a missing or incompletely implemented capability. If we retire the debt by completing the implementation, the MPrin is the cost of that effort, plus any training, testing, and lost revenue. If we retire the debt by halting or withdrawing the capability, the MPrin is the total cost of removal, plus testing and lost revenue.
  • MPrin when standards or regulations change
    The Metaphorical Principal of a technical debt that’s incurred as a result of a change in standards or regulations, internal or external, is the cost of bringing all affected assets into full compliance. Properly accounted for, however, the MPrin should include ripple effects, which are the changes in other assets that are required to keep them compatible with the assets that are directly affected.
  • MPrin in a platform component upgrade
    Platform component upgrades often trigger the need to make changes in whatever sits atop the platform, to maintain compatibility with the platform. Those changes obviously contribute to MPrin. But less obvious are the contributions that arise from deferring the upgrade.
  • MPrin in a development project
    The MPrin of an asset that is subjected to new development or enhancement has some special characteristics. For an existing asset, new development can lead to duplication of capability. For new assets, unanticipated opportunities can transform into technical debt components that were not viewed as technical debt, without ever changing them in any way.
  • Examples of MPrin in four scenarios
    Some examples might help to clarify the differences between the principal of financial debts and the Metaphorical Principal of a technical debt. The examples to come in the next four posts are designed to illustrate the unique properties of MPrins of technical debts.
  • The metaphorical principal of a technical debt
    The principal amount of a financial debt and the metaphorical principal of a technical debt have very different properties. They are so different that it’s wise to avoid using the term “principal” to refer to the metaphorical principal of a technical debt. We use the term MPrin.
Posted on

Debt contagion: how technical debt can create more technical debt

Last updated on July 7th, 2021 at 11:08 am

Decisions to defer technical debt retirement must take into account phenomena that if left unattended can lead to three undesirable outcomes. First, deferring technical debt retirement can increase the volume of the deferred class of technical debt. Second, deferring technical debt retirement can increase the volume of other existing classes of technical debt. And third, deferring technical debt retirement can generate new classes of technical debt.

An example of debt contagion

Suppose Working at a computerwe have a fleet of desktop computers, running a mix of operating systems. A few of these systems are running Windows 8 and the rest are running Windows 10. We’d like to upgrade the Windows 8 machines to Windows 10, but we can’t, because some of their users need access to a (fictional) scriptable application called CRUSH. CRUSH isn’t available for Windows 10. CRUSH for Windows 10 is promised “shortly.”

Instead of asking our CRUSH users to find an alternative to CRUSH, we defer the Windows 8 upgrade. We’re hoping that CRUSH for Windows 10 will soon arrive. Meanwhile, other Windows 8 users are happy to continue using Windows 8. Some of them have acquired—and have grown fond of using—another similar (fictional) scriptable package called REMOTE. REMOTE is also unavailable for Windows 10. Worse, the CRUSH user community is continuing to grow.

Thus, by deferring the Windows 8 upgrade, we’ve made space for additional problems preventing the upgrade to Windows 10. The technical debt associated with the Windows 8 upgrade now includes Windows 8 itself, and all the scripts, documents, and knowledge that are accumulating for both CRUSH and REMOTE.

Lessons learned from this example

The lesson here isn’t to ban scriptable applications. Nor is the lesson to compel desktop users to adhere to an enterprise standard. Both options create numerous problems. The main lesson this example provdes is that deferring debt retirement can enable formation of new instances of existing technical debt. In this example, the new debt includes the growth of the CRUSH user community with the assets they continue to develop, New debt also includes unrelated debt connected with the introduction of REMOTE. Thus, if we defer retirement of one class of technical debt, we must consider all costs of such deferment. Those additional costs can include expansion of the total volume of technical debt, and all its consequences, as expressed as metaphorical interest charges and MPrin.

Some of the new technical debt that forms when we leave existing debt in place is closely related to the existing debt. For example, once we’ve implemented some part of an asset in a way that we now acknowledge contains a form of technical debt, we tend to apply that same approach when we undertake extensions or enhancements, rather than using what everyone might acknowledge is a superior approach.

Introduction to debt contagion

Martini and Bosch have identified a phenomenon they call debt contagion [Martini 2015]. Because of debt contagion, creating new system elements in forms compatible with elements already identified as debt causes debt propagation. This practice helps us maintain some degree of uniformity in the asset, recognizing that in doing so we’re increasing the MPrin of a given class of technical debt. These future expansions of MPrin can be difficult to predict at the time we first incur the debt, or at any time.

However, some forms of technical debt are far less discriminating with respect to the kinds of technical debt they spawn. Debt with this property tends to be associated with the processes used to develop or maintain technological assets. In “A policymaker’s definition of technical debt,” we cite Pugh’s example of acceptance test debt as a form of technical debt [Pugh 2010].

Acceptance test debt can reduce the ability of the organization to retire other forms of technical debt. Absent automated acceptance tests, testing system components from which technical debt has recently been removed is less efficient and reliable than it would be if automated acceptance tests were available. This depressed efficiency and reliability retards debt retirement activity. It might even prevent the organization from attempting debt retirement in some circumstances. In a future post, I’ll describe how a deficient regime of reviews and inspections can also lead to incurring new technical debt, or to elevated levels of legacy technical debt.

Last words

Our final example illustrates how hardware and software interfaces can propagate technical debt. This is ironic, because interfaces were conceived to insulate one portion of an asset from others. Given a system S composed of modules, suppose that module M of S provides services other modules of S. M does contain technical debt, of a form whose retirement would simplify M’s interface. Because that change would require changes to the modules that use M’s services, we decide to defer retiring M’s debt. Meanwhile, other projects are introducing new modules into S, and, of course, they must use M’s existing interface. The MPrin of the technical debt associated with M’s interface thus expands.

Unless we provide an alternate version of M (call it M’) or an alternate interface to M, MPrin expansion can repeat whenever new modules appear in S. But even if we do provide alternatives, engineers must consciously adopt them. Although some will, others might not. Some are under severe schedule pressure. Some cannot or will not learn the new approaches. And some receive direct orders not to use the new approaches. The MPrin associated with M can thus continue to expand, albeit perhaps at a reduced rate.

Technical debt, left in place, can grow and spawn new forms of technical debt. Make technical debt retirement a priority.

References

[Boss 2011] Richard W. Boss, “RFID Technology for Libraries,” American Library Association, 2011.

Some libraries are upgrading their book tagging systems from barcodes to RFID tags—what is essentially a platform upgrade. When they do convert, every item in their collections becomes an instance of technical debt until it’s tagged with an RFID. A tagging technician can process about 1,000 items per day. It’s a big job. Available: here; Retrieved: November 21, 2017

Cited in:

[Broverman 2017] Neal Broverman. “The Success of the Gold and Expo Lines Has Taken a Toll on Bus Ridership,” Los Angeles Magazine, March 30, 2017.

Available: here; Retrieved: November 21, 2017

Cited in:

[Martini 2015] A. Martini and J. Bosch. “The danger of architectural technical debt: Contagious debt and vicious circles,” Working IEEE/IFIP Conf. Softw. Arch., 2015.

Cited in:

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

Cited in:

[Volpe 2017] Volpe National Transportation Systems Center. “Truck Side Guards Resource Page,” October 2017.

Available: here; Retrieved: November 22, 2017

Cited in:

Related posts

  • MPrin for missing or incomplete capability
    In some instances, technical debt is actually a missing or incompletely implemented capability. If we retire the debt by completing the implementation, the MPrin is the cost of that effort, plus any training, testing, and lost revenue. If we retire the debt by halting or withdrawing the capability, the MPrin is the total cost of removal, plus testing and lost revenue.
  • MPrin when standards or regulations change
    The Metaphorical Principal of a technical debt that’s incurred as a result of a change in standards or regulations, internal or external, is the cost of bringing all affected assets into full compliance. Properly accounted for, however, the MPrin should include ripple effects, which are the changes in other assets that are required to keep them compatible with the assets that are directly affected.
  • MPrin in a platform component upgrade
    Platform component upgrades often trigger the need to make changes in whatever sits atop the platform, to maintain compatibility with the platform. Those changes obviously contribute to MPrin. But less obvious are the contributions that arise from deferring the upgrade.
  • MPrin in a development project
    The MPrin of an asset that is subjected to new development or enhancement has some special characteristics. For an existing asset, new development can lead to duplication of capability. For new assets, unanticipated opportunities can transform into technical debt components that were not viewed as technical debt, without ever changing them in any way.
  • Examples of MPrin in four scenarios
    Some examples might help to clarify the differences between the principal of financial debts and the Metaphorical Principal of a technical debt. The examples to come in the next four posts are designed to illustrate the unique properties of MPrins of technical debts.
  • The metaphorical principal of a technical debt
    The principal amount of a financial debt and the metaphorical principal of a technical debt have very different properties. They are so different that it’s wise to avoid using the term “principal” to refer to the metaphorical principal of a technical debt. We use the term MPrin.
Posted on

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:

[Boss 2011] Richard W. Boss, “RFID Technology for Libraries,” American Library Association, 2011.

Some libraries are upgrading their book tagging systems from barcodes to RFID tags—what is essentially a platform upgrade. When they do convert, every item in their collections becomes an instance of technical debt until it’s tagged with an RFID. A tagging technician can process about 1,000 items per day. It’s a big job. Available: here; Retrieved: November 21, 2017

Cited in:

[Broverman 2017] Neal Broverman. “The Success of the Gold and Expo Lines Has Taken a Toll on Bus Ridership,” Los Angeles Magazine, March 30, 2017.

Available: here; Retrieved: November 21, 2017

Cited in:

[Martini 2015] A. Martini and J. Bosch. “The danger of architectural technical debt: Contagious debt and vicious circles,” Working IEEE/IFIP Conf. Softw. Arch., 2015.

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:

[Volpe 2017] Volpe National Transportation Systems Center. “Truck Side Guards Resource Page,” October 2017.

Available: here; Retrieved: November 22, 2017

Cited in:

Related posts

  • MPrin for missing or incomplete capability
    In some instances, technical debt is actually a missing or incompletely implemented capability. If we retire the debt by completing the implementation, the MPrin is the cost of that effort, plus any training, testing, and lost revenue. If we retire the debt by halting or withdrawing the capability, the MPrin is the total cost of removal, plus testing and lost revenue.
  • MPrin when standards or regulations change
    The Metaphorical Principal of a technical debt that’s incurred as a result of a change in standards or regulations, internal or external, is the cost of bringing all affected assets into full compliance. Properly accounted for, however, the MPrin should include ripple effects, which are the changes in other assets that are required to keep them compatible with the assets that are directly affected.
  • MPrin in a platform component upgrade
    Platform component upgrades often trigger the need to make changes in whatever sits atop the platform, to maintain compatibility with the platform. Those changes obviously contribute to MPrin. But less obvious are the contributions that arise from deferring the upgrade.
  • MPrin in a development project
    The MPrin of an asset that is subjected to new development or enhancement has some special characteristics. For an existing asset, new development can lead to duplication of capability. For new assets, unanticipated opportunities can transform into technical debt components that were not viewed as technical debt, without ever changing them in any way.
  • Examples of MPrin in four scenarios
    Some examples might help to clarify the differences between the principal of financial debts and the Metaphorical Principal of a technical debt. The examples to come in the next four posts are designed to illustrate the unique properties of MPrins of technical debts.
Show Buttons
Hide Buttons