How technical debt can create more technical debt

Last updated on November 28th, 2017 at 11:29 am

SummaryAlthough the MPrin of a given can increase or decrease even if instances of that debt remain untouched, the total volume of all other technical debt can change as well. If a class of technical debt is allowed to remain outstanding, its volume can increase as a consequence of seemingly unrelated actions or decisions. Moreover, its existence can cause increases in the volume of other existing classes of technical debt, and its existence can lead to the formation of new classes of technical debt. When formulating technical debt management policy, it's essential to understand these mechanisms and risks.

Decisions to defer technical debt retirement must take into account phenomena that, if left unattended, can lead to (a) increasing volume of a given , (b) increasing volume of other existing classes of technical debt, and (c) generating 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 cannot, because some of their users need access to a (fictional) scriptable application called CRUSH that is not 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, in the hope that CRUSH for Windows 10 will soon arrive. Meanwhile, other Windows 8 users are happy to continue using Windows 8, and some of them have acquired — and have grown fond of using — another similar (fictional) scriptable package called REMOTE, which is also unavailable for Windows 10. Worse, the CRUSH user community is continuing to grow. Thus, by deferring the Windows 8 upgrade, we have 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 to compel desktop users to adhere to an enterprise standard. Both options create numerous problems. The point of the example is merely that deferring debt retirement can enable formation of new instances of existing technical debt (the growth of the CRUSH user community and the assets they continue to develop) and new, unrelated debt (the introduction of REMOTE). Thus, if we make a decision to defer retirement of a class of technical debt, we must consider all costs of such deferment, including 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. 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 effectively 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 technical 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 technical debt. In the absence of 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, which retards debt retirement activity and which might even prevent the organization from attempting debt retirement in some circumstances. In a future post, we shall 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.

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, retiring the debt has been deferred. Meanwhile, new modules are being introduced 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 are introduced into 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. Those who are under severe schedule pressure, or those who cannot or will not learn the new approaches, or those who are directed not to use the new approaches, might continue to use the familiar approaches as long as they are able. 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

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

Related posts

Glossary and Terminology

Last updated on October 8th, 2019 at 07:27 am

Even though technical debt has been with us for a very long time—probably since the time we began inventing technologies—the study of technical debt is relatively new. Ward Cunningham coined the term technical debt in 1992, and its meaning has evolved since then. Because universally accepted definitions for the term and associated concepts have not yet emerged, it seems necessary to have a page on this site that collects definitions.

Asset-exogenous technical debt

Exogenous technical debt is asset-exogenous when it’s brought about by an activity external to an asset, but internal to the enterprise. For example, a change in standards or regulations by some body within the enterprise can cause an asset to incur an asset-exogenous technical debt.

ATD

See Auxiliary technical debt.

Auxiliary technical debt

In the context of a Technical Debt Retirement Project (DRP) that has as an objective retiring from a specified set of assets a particular kind or particular kinds of technical debt, the ATD is the collection of instances of any other kinds of technical debt other than the kind that the DRP is trying to retire. More: “Rules of engagement for auxiliary technical debt

Class of technical debt

On occasion, we speak of classes of technical debt and instances of that class. This can be confusing, because the words class and instance have particular meanings in software engineering. That’s not the sense in which we use the terms here. In this blog, a class of technical debt is just a collection of instances of the same kind of debt. For example, consider the “ghost ramp” described in “Technical debt in the highway system.” It belongs to the class of ghost ramps. If we were maintaining the highway system of Massachusetts, it might be convenient to consider the class of ghost ramp technical debt if we want to let a contract to demolish all ghost ramps. Each ghost ramp would then be an instance of that class.

Cognitive bias

A cognitive bias is the human tendency to make systematic errors based not on evidence, but on factors related to the thought process. Psychologists have identified and demonstrated hundreds of cognitive biases, including several that could plausibly explain failures in priority setting for technical debt retirement projects.

Confirmation bias

Confirmation bias is a cognitive bias. It’s the human tendency to favor and seek only information that confirms our preconceptions, or to avoid information that disconfirms them. For example, the homogeneity of cable news channel audiences, and the alignment between preconceptions of the audience and the slant of the newscast for that channel, are results of confirmation bias. More: “Confirmation bias and technical debt

Debt contagion

If a class of technical debt is allowed to remain outstanding, its volume can increase as a consequence of seemingly unrelated actions or decisions. Moreover, its existence can cause increases in the volume of other existing classes of technical debt, and its existence can lead to the formation of new classes of technical debt. This process is called debt contagion. More: “How technical debt can create more technical debt

DRP

In this blog, I use the term DRP to mean a (technical) Debt Retirement Project. A DRP is a project that has as an objective retiring from a specified set of assets a particular kind of technical debt (or particular kinds of technical debt). Many projects have objectives of debt retirement, at some point or other. But DRPs differ from most, in that debt retirement is their primary objective—indeed, it might be their sole objective. More: “Nine indicators of wickedness

Echo release

An echo release of an asset is a release version whose primary purpose is technical debt retirement. Typically, it’s created immediately following a release version that has created some incremental technical debt, hence the term “echo release.” The echo release is then executed to retire that incremental technical debt, and not to repair defects or add capability. More: “Accounting for technical debt

Endogenous technical debt

When we think of technical debt, we tend to think of activities that produce it relatively directly. We often imagine it as resulting solely from engineering activity, or from decisions not to undertake engineering activity. In either case the activity involved, whether undertaken or not, is activity directly involving the asset that carries the technical debt. This kind of technical debt is endogenous technical debt. The word endogenous comes from the Greek endo– (within or inside) + –genous (related to producing).  So endogenous technical debt is that portion of an asset’s debt that comes about from activity or decisions that directly involve the asset. More: “Exogenous technical debt

Enterprise-exogenous technical debt

Exogenous technical debt is enterprise-exogenous when it’s brought about by an activity external to the enterprise. For example, a change in standards or regulations by some body outside the enterprise can cause an asset to incur an enterprise-exogenous technical debt.

Exogenous technical debt

Technical debt is exogenous when it’s brought about by an activity not directly related to the assets in which the debt appears. The word exogenous comes from the Greek exo– (outside) + –genous (related to producing). So exogenous technical debt is that portion of an asset’s debt that comes about from activity or decisions that don’t involve the asset directly. More: “Exogenous technical debt

Ill-structured problem

An ill-structured problem is a problem that isn’t a well-structured problem [Simon 1973]. An example of an ill-structured problem is finding a definition for ill-structured problems. Another: designing a computer programming language. Still another, even more to the point: deciding when to retire a particular class of technical debt. NDM is more likely to be successful with ill-structured problems than is RDM.

Incremental technical debt

Incremental technical debt is either newly incurred exogenous technical debt, or technical debt that’s incurred in the course of work currently underway or just recently completed. For example, in an apartment building hallway renovation project, workmen did insert expansion joints in the sheetrock they replaced, but on the first three floors they completed, the joints were too widely separated. The remaining 22 floors were done correctly. Nine additional joints on each of the incorrect floors must be inserted eventually. The missing joints, which constitute incremental technical debt, will be inserted after the job is completed. More: “Controlling incremental technical debt

Instance of technical debt

See “Class of technical debt

Intertemporal choice

Confronted with advice from technical experts regarding the urgent need to address the burden of enterprise technical debt, decision makers must consider an unpleasant possibility. To make resources available to retire the technical debt, it might be necessary to temporarily defer investment in some new products or enhancing some existing products. And if they make the recommended investments in technical debt retirement, customers won’t benefit in any visible way. So the choice reduces to one between new products and enhancements relatively sooner, versus retiring technical debt and only later attending to new products and enhancements of existing products. This dilemma is an example of what behavioral economists call intertemporal choice [Loewenstein 1992].

Key Performance Indicator (KPI)

A Key Performance Indicator (KPI) is a metric that provides meaningful insight that’s used to guide business decisions. All KPIs are metrics; not all metrics are KPIs. More: “Metrics for technical debt management: the basics

Legacy technical debt

Legacy technical debt is technical debt associated with an asset, and which exists in any form prior to undertaking work on that asset. For example, in planning a project to renovate the hallways and common areas of a high-rise apartment building, Management discovers that beneath the existing carpeting is a layer of floor tile containing asbestos. Management has decided to remove the tile. In this context, the floor tile can be viewed as legacy technical debt. It isn’t directly related to the objectives of the current renovation, but removing it will enhance the safety of future renovations, enable certification of the building as asbestos-free, and reduce the cost of eventual demolition. More: “Exogenous technical debt

Localizable technical debt

Localizable technical debt is technical debt that manifests itself as discrete chunks. Each instance is self-contained, and we can “point” to it as an instance of the debt in question. For example, if the organization regards Windows 10 as the current operating system for personal computers, and early versions of Windows as technical debt, the each computer that runs and earlier version of Windows is an instance of that technical debt. Each instance is discrete and localized. More: “Retiring localizable technical debt

Measure

A measure is the result of determining the value of a quantifier. For example, we might use the quantifier’s definition to determine a measure of how much human effort has been expended on an asset in the past fiscal quarter. More: “Metrics for technical debt management: the basics

Metric

A metric is an arithmetic formula expressed in terms of constants and a set of measures. One of the simpler metrics consists of a single ratio of two measures. For example, the metric that captures the average cost of acquiring a new customer in the previous fiscal quarter is the ratio of two measures, namely, the investment made in acquiring new customers, and the number of new customers acquired. More: “Metrics for technical debt management: the basics

MICs, or metaphorical interest charges

MICs are the metaphorical interest charges associated with a technical debt. They aren’t interest charges in the financial sense; rather, the MICs of a technical debt represent the total of reduced revenue, lost opportunities, and increased costs of all kinds borne by the enterprise as a consequence of carrying that technical debt. Because the properties of MICs are very different from the properties of financial interest charges, we use the term MICs to avoid confusion with the term interest from the realm of finance. More: “How financial interest charges differ from interest charges on technical debt

MPrin, or metaphorical principal

The MPrin of a technical debt at a give time T is the total cost of retiring that debt at time T. The total cost includes all cost factors: labor, equipment, service interruptions, revenue delays, anything. It even includes the ongoing costs of repairing defects introduced in the debt retirement process. More: “The metaphorical principal of a technical debt

Naturalistic decision-making

Naturalistic decision-making (NDM) entails situation assessment and evaluation of a single option to select a satisfactory option. [Zannier 2007] Features that define naturalistic decision-making are “time pressure, high stakes, experienced decision makers, inadequate information (information that is missing, ambiguous, or erroneous), ill-defined goals, poorly defined procedures, cue learning, context (e.g., higher-level goals, stress), dynamic conditions, and team coordination.”  [Klein 2017]

Non-strategic technical debt

Non-strategic technical debt is technical debt that appears in the asset without strategic purpose. We tend to introduce non-strategic technical debt by accident, or as the result of urgency, or from changes in standards, laws, or regulations—almost any source other than asset-related engineering purposes. And at times, it appears in the asset as a result of external events beyond the boundaries of the enterprise. More: “Non-technical precursors of non-strategic technical debt

The planning fallacy

The planning fallacy is a cognitive bias that causes planners to underestimate costs and schedules, and over-promise benefits, because they pay too little heed to past experience on similar efforts, and rely too much on what they believe will happen on the effort they’re planning. First identified in a 1977 report by Daniel Kahneman and Amos Tversky [Kahneman 1977] [Kahneman 1979]. More: “Unrealistic optimism: the planning fallacy and the n-person prisoner’s dilemma

Policy

Organizational policy is the framework of principles that guide policymakers, decision makers, and everyone in the organization as they carry out their responsibilities. Policy might be written or not, but written policy is more likely to consistently adhered to. Interestingly, the body of organizational policy is itself subject to accumulating technical debt. More: “What is policy?

Policymaker

As I use the term in this blog, a policymaker is someone who is responsible for developing, revising, or approving organizational policies that affect technical debt management. More: “Who are the policymakers?

Quantifier

A quantifier is a specification for a measurement process designed to yield a numeric representation of some attribute of an asset or process. Quantifiers are used to obtain the values called measures, which in turn are used in computing metrics. More: “Metrics for technical debt management: the basics

Rational decision-making

Rational decision-making (RDM) is an approach to making a choice of an option from among a set of options by selecting the option that is optimal with respect to a set of quantitative criteria. [Zannier 2007] Rational choice strategies generally follow this framework: (1) Identify a set of options; (2) Identify criteria for evaluating them; (3) Assign weight to each evaluation criterion; (4) Rate the options relative to the criteria; (5) Choose the option with the highest score. Many different frameworks for implementing this strategy are available, some specialized to specific subject domains [Thokala 2016].

Refactoring

Fowler defines refactoring as “the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure” [Fowler 1999]. Although refactoring is a term specific to software development processes, the concept applies to all technological development. For example, an automobile manufacturer’s decision to alter the design of one of their model vehicles to reduce manufacturing costs can be viewed as a form of refactoring. Refactoring is a practice essential to effective technical debt management. More: “Refactoring for policymakers

Regression testing

Regression testing is a testing regimen that ensures that a previously developed and tested system still performs the same way after it has been altered or when it’s used in a new context. Regression testing is essential when we alter a system by retiring some of its technical debt.

The reification error

The reification error (also called the reification fallacy, concretism, or the fallacy of misplaced concreteness) is an error of reasoning in which we treat an abstraction as if it were a real, concrete, physical thing. Reification is useful in some applications, such as object-oriented programming and design. But when we use it in the domain of logical reasoning, troubles can arise. Specifically, we can encounter trouble when we think of “measuring” technical debt. Strictly speaking, we cannot measure technical debt. We can estimate the cost of retiring it, but estimates are only approximations. And in the case of technical debt, the approximations are usually fairly rough. To regard these estimates as measurements is to risk reifying them. Then when the actual cost of a debt retirement project is dramatically larger than the estimate, the consequences for enterprise budgets can be severe. We must always regard “measurements” of technical debt as estimates—estimates that are so prone to error that we must plan for error.  The reification error is the dual of the resilience error. More: “Metrics for technical debt management: the basics.”

The resilience error

If the reification error is an error of reasoning in which we treat an abstraction as if it were a real, concrete, physical thing, the resilience erroris an error of reasoning in which we treat an abstraction as if it were more flexible, resilient, and adaptable than it actually is. When we commit the resilience error with respect to an abstraction, we adopt the belief—usually without justification, and possibly outside our awareness—that if we make changes in the abstraction without fully investigating the consequences of those changes, we can be certain that the familiar properties of the abstraction we modified will apply, suitably modified, to the new form of the abstraction.  Or we assume incorrectly that the abstraction will accommodate any changes we make to its environment. The resilience error is the dual of the reification error. We are at risk of making the resilience error when we refactor assets to reduce their burden of technical debt. More: “The resilience error and technical debt.”

Secured technical debt

A secured technical debt, like a secured financial debt, is one for which the enterprise has reserved the resources needed to retire the debt. However, unlike a financial debt, the resources required to retire a technical debt might not be purely financial. They might include particular staff, equipment, test beds, downtime, and financial resources. The commitment might extend beyond the current fiscal period. Secured technical debt is a powerful means of driving down total technical debt burden, but it might require modification of internal budget management processes and fiscal reporting. Policymakers can help in designing and deploying the necessary changes. More: “Using SMART goals for technical debt reduction

Source and target components of a metaphor

In a metaphor of the form “A is B,” the source is the element whose attributes are being attributed to the target. For example, in “my son’s room is a war zone,” the source is the war zone, and the target is my son’s room.  More: “The structure of metaphors

Super wicked problem

A subset of wicked problems can be viewed as super wicked [Levin 2012]. Levin, et al. list the following four properties of super wicked problems: (1) Time is running out; (2) Those who cause the problem also seek to provide a solution or influence the solution; (3) The central authority needed to address the problem is weak, non-existent, or chooses not to act effectively; (4) Policy responses discount the future irrationally. I’ve come to believe that some technical debt retirement project design can be a super wicked problem. More: “Retiring technical debt can be a super wicked problem

Taylorism

Taylorism is an approach to management developed by Frederick Winslow Taylor in the early part of the twentieth century [Taylor 1913] [Kanigel 1997]. He proposed three principles of scientific management could produce maximum efficiency: (1) scientific selection of the person performing the work; (2) scientific breakdown of tasks; and (3) separating planning from execution. These principles are the basis of what became known in software engineering as the waterfall lifecycle. The approach works well for well-structured problems, but does not work well at all for ill-structured problems. Moreover, it depends for success on repeating solutions to problems already solved, which is why it proved so valuable in early manufacturing. Its unsuitability for ill-structured problems is an important part of the basis for the Agile approach to problem solving.

TDIQ

In the context of a Technical Debt Retirement Project (DRP) that has as an objective retiring from a specified set of assets a particular kind of technical debt (or particular kinds of technical debt), the TDIQ is the Technical Debt In Question. More: “Retiring technical debt in irreplaceable assets

Technical debt

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, and which we would therefore 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. More: “A policymaker’s definition of technical debt

Technological communication risk

Technological communication risk is the risk that, for whatever reason, knowledgeable people within the enterprise don’t communicate important knowledge to the people who need it, or the people who need it aren’t receptive to it. More: “Technological communication risk

Temporal discounting

Temporal discounting is the human tendency to give greater value to a reward (or as economists would say, to assign greater utility to a good) the earlier it arrives. An analogous process affects perceptions of inconvenience or disutility: people assign more negative values to penalties and inconveniences the sooner they arrive. If the discount rate is constant, the discounting is termed exponential discounting or rational discounting. But other forms are possible. Hyperbolic discounting is one form of discounting at a rate that is higher for near-term arrivals than for distant-term arrivals [Laibson 1997]. Humans have been observed experimentally to favor a form of temporal discounting that is well modeled as hyperbolic discounting.

Terrifying opportunity

A terrifying opportunity arises when the organization rejects (or fails to recognize) a market opportunity because exploiting it would involve modifying an existing asset or product offering that harbors a heavy load of technical debt. The debt causes decision-makers to assess that the probability of success is so low that the opportunity seems terrifying, and they therefore reject the opportunity. More: “MICs on technical debt can be difficult to measure

Well-structured problem

As defined by Simon [Simon 1973], a well-structured problem is a problem that has some or all of six characteristics. The first is the existence of a definite criterion for testing any proposed solution, and a mechanizable process for applying that criterion. Second, there is at least one problem space in which we can represent the initial problem state, the goal state, and all states that can be reached or considered while solving the problem. There are four more criteria, but these are the biggies. An example of a well-structured problem is the game of chess. RDM is useful for attacking well-structured problems.

Wicked problem

A problem is a wicked problem if it meets the ten criteria established by Rittel and Webber [Rittel 1973]. Four of the criteria: it’s an ill-structured problem; it’s incompletely defined or internally contradictory; its solutions are not true-or-false, but good-or-bad; and there’s no way to exhaustively describe all solutions. I’m convinced that technical debt retirement project design can be a wicked problem. More: “Self-sustaining technical knowledge deficits during contract negotiations.”

References

[Fowler 1999] Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, Don Robert, Erich Gamma (Foreword). Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley Professional; first edition (July 8, 1999).

Order from Amazon

Cited in:

[Kahneman 1977] Daniel Kahneman and Amos Tversky. “Intuitive Prediction: Biases and Corrective Procedures,” Technical Report PTR-1042-7746, Defense Advanced Research Projects Agency, June 1977.

Available: here; Retrieved: September 19, 2017

Cited in:

[Kahneman 1979] Daniel Kahneman and Amos Tversky, “Intuitive Prediction: Biases and Corrective Procedures,” Management Science 12, 313-327, 1979.

Cited in:

[Kanigel 1997] Robert Kanigel. The one best way: Frederick Winslow Taylor and the enigma of efficiency. Viking Penguin, 1997.

Order from Amazon

Cited in:

[Klein 2017] Gary Klein. Sources of Power: How People Make Decisions, 20th Anniversary Edition. Cambridge, Massachusetts: The MIT Press, 1999.

Order from Amazon

Cited in:

[Laibson 1997] David Laibson. “Golden eggs and hyperbolic discounting,” Quarterly Journal of Economics 112:2, 1997, 443-477.

Available: here; Retrieved: October 25, 2018

Cited in:

[Levin 2012] Kelly Levin, Benjamin Cashore, Steven Bernstein, and Graeme Auld. “Overcoming the tragedy of super wicked problems: constraining our future selves to ameliorate global climate change,” Policy Science 45, 2012, 123–152.

Available: here; Retrieved: October 17, 2018

Cited in:

[Loewenstein 1992] George Loewenstein and Drazen Prelec. “Anomalies in Intertemporal Choice: Evidence and an Interpretation,” Quarterly Journal of Economics, 57:2, 1992, 573-598.

Available: here; Retrieved: October 12, 2018

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:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

[Simon 1973] Herbert A. Simon. “The Structure of Ill Structured Problems,” Artificial Intelligence 4, 1973, 181-201.

Available: here; Retrieved: 10/16/18

Cited in:

[Taylor 1913] Frederick Winslow Taylor. The Principles of Scientific Management. New York: Harper & Brothers, 1913.

Available: here; Retrieved: October 16, 2018 Order from Amazon

Cited in:

[Thokala 2016] Praveen Thokala, Nancy Devlin, Kevin Marsh, Rob Baltussen, Meindert Boysen, Zoltan Kalo, Thomas Longrenn et al. “Multiple Criteria Decision Analysis for Health Care Decision Making—An Introduction: Report 1 of the ISPOR MCDA Emerging Good Practices Task Force,” Value in Health 19:1, 2016, 1-13.

Available: here; Retrieved: 10/16/18

Cited in:

[Zannier 2007] Carmen Zannier, Mike Chiasson, and Frank Maurer. “A model of design decision making based on empirical results of interviews with software designers,” Information and Software Technology 49, 2007, 637-653.

Available: here; Retrieved October 15, 2018

Cited in:

Policy implications of the properties of MPrin

Last updated on May 21st, 2019 at 05:38 pm

Formulating sound policy vis-à-vis technical debt requires a thorough understanding of the distinction between the MPrin associated with a technical debt and the principal amount of a financial debt. There are three fundamental differences between them.

MPrin can change spontaneously

For most financial debts, a formula determines the principal amount. Voluntary actions of the debtor can also affect the principal amount. For example, the debtor might make periodic payments on an installment loan, or new purchases on a credit card account. By contrast, MPrin of a technical debt can change absent any action by the “borrower.” For example, changes in regulations, standards, or technologies can all cause changes in MPrin. More: “How MPrin can change spontaneously

Technical debt can create more technical debt

Technical debt left in place can create more technical debt without the knowledge or consent of the debtor organization. By contrast, the principal amount of a financial debt can grow, but law or regulation requires notification—and in some cases consent—of the debtor. More: “How MPrin can change spontaneously

Projecting MPrin with useful precision might not be possible

The cost of retiring a technical debt can depend on how the asset bearing the debt has changed over the life of the debt. And it can depend on what other projects the enterprise is executing debt retirement time. These factors are difficult to predict. By contrast, projecting the principal amount of a financial debt is formulaic. More: “Useful projections of MPrin might not be attainable

A pole full of wires
A pole full of wires. Technical debt is everywhere.

The policy implications of these properties of MPrin can be profound. The possibility of spontaneous change in MPrin implies a need for investments in market and technological intelligence focused specifically on potential effects on technical debt. Moreover,  existing technical debt can cause the creation of new instances of that debt or other debts. This “contagion” implies a need for awareness of what kinds of technical debt are most likely to exhibit this phenomenon. Finally, the difficulty of projecting MPrin implies that typical reliance on analytical modeling of enterprise asset evolution in preference to human judgment may be misplaced. A wiser course might be investment in employee retention programs focused on the individuals who can provide the necessary wisdom.

This is just a sketch of the problems policymakers confront when dealing with the properties of MPrin. I’ll be addressing them in more detail in future posts.

References

[Fowler 1999] Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, Don Robert, Erich Gamma (Foreword). Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley Professional; first edition (July 8, 1999).

Order from Amazon

Cited in:

[Kahneman 1977] Daniel Kahneman and Amos Tversky. “Intuitive Prediction: Biases and Corrective Procedures,” Technical Report PTR-1042-7746, Defense Advanced Research Projects Agency, June 1977.

Available: here; Retrieved: September 19, 2017

Cited in:

[Kahneman 1979] Daniel Kahneman and Amos Tversky, “Intuitive Prediction: Biases and Corrective Procedures,” Management Science 12, 313-327, 1979.

Cited in:

[Kanigel 1997] Robert Kanigel. The one best way: Frederick Winslow Taylor and the enigma of efficiency. Viking Penguin, 1997.

Order from Amazon

Cited in:

[Klein 2017] Gary Klein. Sources of Power: How People Make Decisions, 20th Anniversary Edition. Cambridge, Massachusetts: The MIT Press, 1999.

Order from Amazon

Cited in:

[Laibson 1997] David Laibson. “Golden eggs and hyperbolic discounting,” Quarterly Journal of Economics 112:2, 1997, 443-477.

Available: here; Retrieved: October 25, 2018

Cited in:

[Levin 2012] Kelly Levin, Benjamin Cashore, Steven Bernstein, and Graeme Auld. “Overcoming the tragedy of super wicked problems: constraining our future selves to ameliorate global climate change,” Policy Science 45, 2012, 123–152.

Available: here; Retrieved: October 17, 2018

Cited in:

[Loewenstein 1992] George Loewenstein and Drazen Prelec. “Anomalies in Intertemporal Choice: Evidence and an Interpretation,” Quarterly Journal of Economics, 57:2, 1992, 573-598.

Available: here; Retrieved: October 12, 2018

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:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

Cited in:

[Simon 1973] Herbert A. Simon. “The Structure of Ill Structured Problems,” Artificial Intelligence 4, 1973, 181-201.

Available: here; Retrieved: 10/16/18

Cited in:

[Taylor 1913] Frederick Winslow Taylor. The Principles of Scientific Management. New York: Harper & Brothers, 1913.

Available: here; Retrieved: October 16, 2018 Order from Amazon

Cited in:

[Thokala 2016] Praveen Thokala, Nancy Devlin, Kevin Marsh, Rob Baltussen, Meindert Boysen, Zoltan Kalo, Thomas Longrenn et al. “Multiple Criteria Decision Analysis for Health Care Decision Making—An Introduction: Report 1 of the ISPOR MCDA Emerging Good Practices Task Force,” Value in Health 19:1, 2016, 1-13.

Available: here; Retrieved: 10/16/18

Cited in:

[Zannier 2007] Carmen Zannier, Mike Chiasson, and Frank Maurer. “A model of design decision making based on empirical results of interviews with software designers,” Information and Software Technology 49, 2007, 637-653.

Available: here; Retrieved October 15, 2018

Cited in:

Related posts

The metaphorical principal of a technical debt

Last updated on November 21st, 2017 at 09:05 am

The “principal” amount of a technical debt is not 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. Built in 1783 as a jailer’s house, it served as a debtors’ prison from 1824 to 1849. Debtors imprisoned there were required to work to earn their keep and to retire their debt, if they could not find other means to do so. Today, bankruptcy laws facilitate seizure of property to retire debts, a much more enlightened approach. Requiring the product or service engineering functions to fund technical debt retirement efforts through expense budgets is analogous to debtors’ prison. A more enlightened approach is needed.  Photo (cc) Ser Amantio di Nicolao, courtesy Wikimedia Commons.

In the field of finance, the principal amount of a loan at the time of origination is the amount that was borrowed. Over time, as the debtor makes payments according to the terms of typical loan agreements, the principal either remains constant, in which case it’s repaid in a lump sum at a specified date, or it declines gradually, in increments, with each payment. This is the widely accepted layperson’s definition, and it’s the basis of the association people make with respect to the metaphorical principal amount of a technical debt.

That’s unfortunate. Because the metaphorical principal amounts of most technical debts behave very differently from the principal amounts of financial debts, using the term principal to refer to the metaphorical principal associated with a given kind of technical debt is risky. The risk arises from confusing financial principal, which is typically fixed or slowly declining, with the metaphorical principal of technical debt, which can exhibit sudden and dramatic fluctuations. These confusions arise because of unintended associations of the technical debt metaphor.

Using an alternative term that makes the metaphor obvious can limit this risk. One such term is metaphorical principal, or for convenience, MPrin.

Although the distinction between the initial principal amount of a technical debt and MPrin is not universally recognized [Seaman 2013], some have addressed it. For example, Avgeriou et al. define the initial principal of a particular class of technical debt as the savings realized by incurring the debt, and the current principal as the resources required to deploy a different or better solution now [Avgeriou 2016].

The initial principal concept of Avgeriou et al. is what we 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 or not to incur the debt, if, indeed, one has an opportunity to make such a decision. However, once the debt has been incurred, the current MPrin is what matters; initial MPrin becomes irrelevant.

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:

[Fowler 1999] Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, Don Robert, Erich Gamma (Foreword). Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley Professional; first edition (July 8, 1999).

Order from Amazon

Cited in:

[Kahneman 1977] Daniel Kahneman and Amos Tversky. “Intuitive Prediction: Biases and Corrective Procedures,” Technical Report PTR-1042-7746, Defense Advanced Research Projects Agency, June 1977.

Available: here; Retrieved: September 19, 2017

Cited in:

[Kahneman 1979] Daniel Kahneman and Amos Tversky, “Intuitive Prediction: Biases and Corrective Procedures,” Management Science 12, 313-327, 1979.

Cited in:

[Kanigel 1997] Robert Kanigel. The one best way: Frederick Winslow Taylor and the enigma of efficiency. Viking Penguin, 1997.

Order from Amazon

Cited in:

[Klein 2017] Gary Klein. Sources of Power: How People Make Decisions, 20th Anniversary Edition. Cambridge, Massachusetts: The MIT Press, 1999.

Order from Amazon

Cited in:

[Laibson 1997] David Laibson. “Golden eggs and hyperbolic discounting,” Quarterly Journal of Economics 112:2, 1997, 443-477.

Available: here; Retrieved: October 25, 2018

Cited in:

[Levin 2012] Kelly Levin, Benjamin Cashore, Steven Bernstein, and Graeme Auld. “Overcoming the tragedy of super wicked problems: constraining our future selves to ameliorate global climate change,” Policy Science 45, 2012, 123–152.

Available: here; Retrieved: October 17, 2018

Cited in:

[Loewenstein 1992] George Loewenstein and Drazen Prelec. “Anomalies in Intertemporal Choice: Evidence and an Interpretation,” Quarterly Journal of Economics, 57:2, 1992, 573-598.

Available: here; Retrieved: October 12, 2018

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:

[Rittel 1973] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a General Theory of Planning”, Policy Sciences 4, 1973, 155-169.

Available: here; Retrieved: October 16, 2018

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:

[Simon 1973] Herbert A. Simon. “The Structure of Ill Structured Problems,” Artificial Intelligence 4, 1973, 181-201.

Available: here; Retrieved: 10/16/18

Cited in:

[Taylor 1913] Frederick Winslow Taylor. The Principles of Scientific Management. New York: Harper & Brothers, 1913.

Available: here; Retrieved: October 16, 2018 Order from Amazon

Cited in:

[Thokala 2016] Praveen Thokala, Nancy Devlin, Kevin Marsh, Rob Baltussen, Meindert Boysen, Zoltan Kalo, Thomas Longrenn et al. “Multiple Criteria Decision Analysis for Health Care Decision Making—An Introduction: Report 1 of the ISPOR MCDA Emerging Good Practices Task Force,” Value in Health 19:1, 2016, 1-13.

Available: here; Retrieved: 10/16/18

Cited in:

[Zannier 2007] Carmen Zannier, Mike Chiasson, and Frank Maurer. “A model of design decision making based on empirical results of interviews with software designers,” Information and Software Technology 49, 2007, 637-653.

Available: here; Retrieved October 15, 2018

Cited in:

Related posts

Show Buttons
Hide Buttons