MPrin in a development project

The MPrin of new technical debt associated with a development project is usually taken to be the difference between the cost of implementing it in a sustainable manner and the cost of simply making it work. The effort saved by choosing the latter over the former is typically identified as the initial MPrin of the technical debt.

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, which created a technical debt in the bus system that is being retired by reducing, rescheduling and re-routing bus service [Broverman 2017].

For example, in an enhancement project for an existing asset, after we finally achieve an operational capability, we might recognize that we have duplicated some functionality that already existed elsewhere in the asset. In such cases, the responsible, debt-free approach would be to first remove the duplication, then to modify the asset to use the previously existing approach, and finally to re-test the asset. By leaving the duplication in place, we save all that effort (and time), which many regard as the MPrin of a 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.

An example of a less obvious process might be insights gained in marketing one product, which we shall call P1, that reveal an opportunity to introduce other related products, P2, P3, and P4, to form a suite. The latter products could employ some of the assets developed for or contained in P1, if they 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 it’s mirrored in the subsequent products.

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


[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:

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.

Unintended associations of the technical debt metaphor

Last updated on February 16th, 2020 at 04:28 pm

Because the term technical debt is a metaphor, it causes us to think in ways that sometimes create barriers to managing technical debt responsibly. Like all metaphors, the technical debt metaphor carries with it unintended associations — attributes of the metaphor’s source that the listener or reader attributes to the metaphor’s target, even though the attributions are not intended by the metaphor’s author. For the technical debt metaphor, these unintended associations relate to the concepts of debtor, principal, and interest, and they can cause enterprise decision-makers to arrive at erroneous decisions.

Because metaphors compel our minds to accept the identification between source and target in toto, they can cause us to make errors of thought. Those errors create risks for the enterprise as we attempt to manage technical debt. The risk arises because we begin to regard technical debt as a form of financial debt, when in reality it is not. This misidentification is an acceptable risk, if we understand the risk and if we manage it properly. Unfortunately, that risk is often unrecognized, and when it’s unrecognized it remains unmitigated. A significant source of this risk is our inability to control which attributes of the metaphor’s source the reader or listener chooses to associate with the metaphor’s target. I call this phenomenon unintended association.

Interest and principal have unintended associations

University graduates celebrate commencement
University graduates celebrate commencement. Some, perhaps most, carry a burden of student loan debt in addition to their diplomas. Student loans, now familiar to many, act as a source for the technical debt metaphor. They are therefore also a source for its unintended associations.

Two sets of unintended associations that frequently arise in the context of the technical debt metaphor relate to interest and principal. In the world of finance we understand these concepts well. Unfortunately, our understanding from finance doesn’t fit well with the details of the corresponding properties of technical debt. For example, van Haaster [van Haaster 2015] writes: “Financial debt has two well understood dimensions: the amount owing and its cost to repay over time, consequently when you take on financial debt, the total cost of that debt over time is either known or can be calculated.” Such beliefs about financial debt have consequences for our thinking about technical debt, because van Haaster’s statement is inapplicable to technical debt, for two reasons. First, the cost to repay a technical debt might not be well known. Second, the interest charges on technical debt might not be known, might not even be knowable, and often cannot be calculated [Falessi 2014]. These are just two examples of differences between financial debt and technical debt. We shall explore these differences in some detail in coming posts.

A most significant unintended association is that related to the concept of debt itself. Consider, for example, the social status of debtors in society. For many, excessive financial debt evokes images of profligate spending, laziness, and moral decay. These associations can hinder technology leaders within organizations as they urgently advocate for resources for technical debt management.

How technical debt can be seen as evidence of mismanagement

Because of unintended association, some decision makers outside the technology-oriented elements of the enterprise might regard technical debt as evidence of mismanagement. They might tend to attribute the cause of technical debt to professional malpractice by technology managers. They see supportive evidence in the technology managers’ uncertainty about the size of the debt or how they acquired the debt. To the extent that nontechnical decision makers adopt this attitude, they are unlikely to support enterprise policy changes. They’re even less likely to support additional resources for technical debt management.

But the problems of the technical debt metaphor can be even more significant. The issue is explained in a classic work of Lakoff and Johnson [Lakoff 1980] in terms of a metaphor (of course). In this metaphor:
  • Ideas are objects
  • Linguistic expressions are containers for ideas
  • Communication is the process of sending the containers along a conduit to a recipient

Metaphors do have a significant weakness. When the recipient receives the container, he or she opens the container and extracts the idea, completing the communication. Unfortunately things are not so simple. Lakoff and Johnson observe that the recipient must interpret the linguistic expressions of the container relative to a context. Because the choice of context is left to the recipient, the breadth of choices possible can determine how well the metaphor serves the sender’s purposes. A broad array of possible context choices gives recipients relative freedom to interpret the linguistic expressions. That freedom is what leads to what I’ve been calling unintended associations.

For example, even within the technology sectors of the enterprise, the technical debt metaphor can create communication problems between technologists and their managers. To technologists, technical debt is unequivocally disfavored. It makes their work more expensive and more annoying, and it limits their ability to enhance the assets for which they are responsible. To management, by contrast, the term debt evokes the idea of financial debt, which is a useful tool when employed responsibly. Non-technologist managers don’t personally experience the frustrations and annoyance that technical debt often causes. They don’t experience the visceral revulsion that technologists feel when contemplating instances of technical debt. The differences in degree of urgency perceived by managers and technologists are therefore due, in part, to the technical debt metaphor and the use of the word debt.

Moreover, when making the case for technical debt retirement, technologists must provide estimates of the scale of the problem, and explain how it arose. Those who interpret the term technical debt against a background of financial experience are likely to be troubled by the technologists’ admissions of total or partial ignorance of what led to the problem, or by their admitted difficulties in providing precise estimates of the cost of retiring the technical debt. Such questions have definite answers for financial debt. For technical debt, they do not, even though the terms financial debt and technical debt share the word debt.

Debates have erupted in the engineering literature about the meaning of the term technical debt. Is incomplete work technical debt if there had not been a conscious decision to postpone it? Is work performed shoddily to meet a tight schedule technical debt? The real problem isn’t ambiguity in the term technical debt; rather, it is that the term is only a metaphor. With regard to the technical debt metaphor, the range of possible interpretations is somewhat wider than some would like. Nearly all metaphors are subject to such problems.

It is this problem — a problem of all metaphors — that accounts for much of the difficulty enterprises have when they try to control technical debt.

But let’s turn now to a closer examination of the two most important unintended associations — principal and interest. We begin with principal next time.


[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:

[Falessi 2014] D. Falessi, P. Kruchten, R.L. Nord, and I. Ozkaya. “Technical Debt at the Crossroads of Research and Practice: Report on the Fifth International Workshop on Managing Technical Debt,” ACM SIGSOFT Software Engineering Notes 39:2, 31-33, 2014.

Available: here; Retrieved: March 16, 2017

Cited in:

[Lakoff 1980] G. Lakoff and M. Johnson, Metaphors We Live By. Chicago: The University of Chicago Press, 1980.

The classic and fundamental study of metaphor. Order from Amazon

Cited in:

[van Haaster 2015] Kelsey van Haaster. “Technical Debt: A Systems Perspective,” Better Projects blog, January 8, 2015.

Available: here; Retrieved: October 2, 2017

Cited in:

Related posts