The Principal Principle: Focus on MICs

Last updated on December 11th, 2018 at 06:56 am

When some organizations first realize that their performance is being limited by technical debt, they begin by chartering a “technical debt inventory.” Their goals are to determine just how much technical debt they’re carrying, where it is, how much retiring it all will cost, and 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. Understandable, but in most cases, ineffective. With technical debt we need a different approach, because technical debt is different from financial debt. With technical debt, we must be guided by 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.

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.

With technical debt, MICs can vary dramatically. For assets that aren’t being maintained or enhanced, the MICs can be Zero for extended periods. For retiring assets, their technical debt can vanish when the asset is retired. For other assets, MICs can be dramatically higher—beyond the total cost of replacing the asset.

Most people regard MICs as being restricted to productivity problems among engineers. I take a different approach. I include in MICs anything that depresses net income—lost or delayed revenue, increased expenses, anything. For instance, if technical debt causes a two-month delay in reaching a market, 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. Drive them to Zero and keep them there.

Other posts in this thread

How financial interest charges differ from interest charges on technical debt

Last updated on December 21st, 2017 at 01:48 pm

Second only to the term debt, the term interest is perhaps the most common financial term in the literature of technical debt. In the financial realm, interest charges are the cost of using money, usually expressed as a percentage rate per unit time.

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, it’s easy to get into debt over your head.

The notion of interest is deep in our culture. People understand it well, but the way they understand it corresponds to interest rates that are fixed, or at worst relatively slowly varying. This understanding creates a bias in the way we understand technical debt, in the sense that we perceive the elements of technical debt as imposing a cost that is 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. Formulating sound technical debt policy depends on understanding the nature of the difference between interest on financial debt and the metaphorical interest charges associated with technical debt.

There are two fundamental reasons why metaphorical interest charges on technical debt differ from the interest on financial debt.
  • Metaphorical interest charges depend strongly on whether and how the people of the enterprise interact with the assets bearing the technical debt.
  • The metaphorical interest charges on technical debt include the value of opportunities lost to the enterprise (opportunity cost) due to depressed productivity and reduced organizational agility.

Neither of these factors has a direct analog in the financial context. In finance, the interest charges depend solely on a mathematical formula based on the interest rate and the size of the principal.

In the next few posts we’ll explore the properties of metaphorical interest charges. This investigation will help clarify how they differ from financial interest charges, and how that difference contributes to difficulties in managing technical debt.

Related posts

MPrin for missing or incompletely implemented capability

Last updated on December 13th, 2017 at 02:05 pm

In some instances, technical debt is actually a missing or incompletely implemented capability. For example, absence of a fully automated regression test suite can create difficulties for testing a complex system after a series of modifications. 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.

A concrete building under construction
A concrete building under construction. Concrete takes about a month to fully cure, and until it cures it doesn’t reach full strength. If we waited for full curing before pouring the floor above, multistory concrete construction would be slow and very expensive. So we start on the next floor after only a few days.  Because the floors of concrete buildings can’t support themselves for about a week or so, they need to be shored up by the floor below, and re-shored by the floors below that. The shoring constitutes a technical debt incurred because of the “incomplete implementation” (partial cure) of each floor. We retire that debt incrementally, floor by floor, by removing the re-shoring as the building gets taller. More about shoring and re-shoring
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, the assets involved can change. Moreover, if retiring the debt  a revenue stream interruption, and that revenue stream grows significantly, the MPrin, which includes the lost revenue, can also grow significantly.

Technical debt associated with incompletely implemented capability presents unique problems, because debt of this kind can be retired 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 altogether. If that happens, retiring the debt completely would require removal of all artifacts that comprise the completed parts of the incomplete implementation. But full retirement can also require that we survey all components that interact with the retiring elements to determine whether they contain accommodations that are no longer necessary. Finally, we can choose a middle path, in which we adopt some parts that have been completed, reject other parts, and add whatever is necessary to create a limited version of what was originally planned.

It’s worth mentioning an important attribute of non-physical assets—software, procedures, legislation, regulations, and so on—that makes the technical debt associated with incomplete implementation so difficult to manage. 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 until the concrete is cured well enough to support itself. They constitute a kind of technical debt that must be “retired” before the building can be completed. The teams constructing the building could never forget to remove the shoring because it gets in the way of installing 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 being tried but didn’t work out. Many non-physical assets are perfectly functional carrying that kind of technical debt. The problems associated with that debt become evident with time, as the asset becomes increasingly difficult to maintain, extend, or defend.

It is 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

Last updated on October 15th, 2018 at 06:51 am

The MPrin of 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. The conventional definition of the MPrin for this kind of technical debt includes only the cost of aligning the existing assets to the new standards or regs. Properly accounted for, however, the MPrin should include ripple effects, which are the changes in other assets that are required not directly by the change in standards or regs, but by the requirement that other assets 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 with the understanding that I mean standards or regulations (or regs) except when I say so explicitly.

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.

The activity required to align existing assets to the new standards can have expensive consequences, which must be included in the calculation of MPrin, but which, unfortunately, are often overlooked or accounted for in other ways. For example, the testing required by the standards alignment effort might require a service interruption or product availability delays or interruptions, which 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, of course, as new assets are developed in compliance with the obsolete standards. Second, and less obvious, perhaps, 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, not because they are not compliant with the new standards, but because they need to be made compatible with the components that are eventually modified to comply with the new standards. In this way, MPrin at debt retirement time can differ from — and greatly exceed — the savings realized when we first  incurred the debt.

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 technical debt they carry vanishes when those assets are retired.


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

Available: here; Retrieved: November 22, 2017

Cited in:

Related posts

Examples of MPrin in four scenarios

Last updated on November 22nd, 2017 at 12:22 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 are designed to 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 sketched below illustrate some of these phenomena. They’re described more completely described posts indicated.

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 is incurred. More: “MPrin in platform component upgrades

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 incompletely implemented 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.

Debt contagion: how technical debt can create more technical debt

Last updated on February 17th, 2020 at 08:10 pm

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

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.

The lesson here is not to ban scriptable applications. Nor is the lesson to compel desktop users to adhere to an enterprise standard. Both options create numerous problems. The point of the example 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], whereby 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].

But 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 interfaces — which, ironically, were conceived to insulate one portion of an asset from others — can act so as to propagate technical debt. This example could apply to either hardware or software. Given a system S composed of several modules, suppose that module M of S provides services of some kind to several other modules of S. M does contain some 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, this process of MPrin expansion can repeat whenever new modules appear in S. But even if we do provide M’ or an alternate interface to M, engineers must consciously refrain from using the older approaches. Some will refrain, but some 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.


[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