Month: November 2017

For financial debts, the interest charges associated with a unit of debt are (usually) the same for every unit of debt incurred under the same loan agreement. But for technical debt, the MICs associated with a given instance of a class of technical debt might differ from the MICs associated with any other instance of the same class of technical debt, even if those instances of technical debt were incurred at the same time as a result of a single decision or sequence of events. Unlike the transactions on a credit card, for instances of the same kind of technical debt the interest charges can vary.

The I-35W Bridge collapse, day 4, Minneapolis, Minnesota, August 5, 2007. The proximate cause of the collapse was underweight gusset plate design, which made the bridge vulnerable to the increased static load due to concrete road surfacing additions over the years, and to the weight of construction equipment and supplies during a repair project that was then underway. But the root cause of the failure was that the design of the bridge was “fracture critical,” meaning that it was vulnerable to collapse if any one of a set of critical bridge members failed. There are 18,000 fracture critical bridges in the U.S. today, and more are under construction. They were built (and are being built) because they’re cheaper to build than are bridges that have zero fracture critical members [CBS News 2013]. Engineering practices like this—expedient shortcuts—are among the most prolific generators of technical debt. The MICs in the case of bridges could include inspections, repairs, and temporary closures for inspections and repairs. Variations in bridge design and usage clearly could create variations in MICs from bridge to bridge. Photo by Kevin Rofidal, United States Coast Guard, courtesy Wikimedia Commons.Here’s why.

For most financial debts, a single algorithm determines the interest charges for every unit of a particular class of financial debt. Following the technical debt metaphor, people tend to assume that the MICs on every instance of a particular class of technical debt are uniform across the asset base.

But in practice, uniformity assumptions with regard to MICs are generally unwarranted. Given two different manifestations of the same kind of technical debt, the MICs associated with modifying asset components in and around those two instances can differ significantly. For any given instance of a particular class of technical debt, MICs can depend on whether or not engineers must interact with that part of the asset. And when they do interact with a given asset component, MICs can also depend upon the transparency and condition of that asset component.

For example, an instance of technical debt might reside in a portion of the system that relatively few local experts understand. The people who are capable of doing that work might be in high demand, or heavily committed, or expensive. Subsequent scheduling difficulty can lead to delays or service interruptions associated with completing the required work. That can result in lost revenue, which also contributes to MICs. Meanwhile, instances of the same kind of technical debt residing in other parts of the asset might be addressable by less expert staff, who might be in lesser demand, and less well compensated. Service interruptions might be shorter, and lost revenue less. The MICs associated with these two cases can therefore differ significantly.

As a second example, consider documentation deficits. If an engineer needs access to documentation to determine how to proceed with a task, and that documentation doesn’t exist, the engineer must resort to alternatives that might be more time-consuming, such as reading code or specifications, or interviewing colleagues. But for two given instances of the same kind of technical debt, the need to refer to documentation can differ. Documentation might be needed for one instance in one part of the asset, but not for another.

Another form of documentation deficit can be especially costly. If documentation is needed, and it does exist, but it’s outdated or incorrect, engineers who rely on that documentation might make costly, potentially irreversible errors when they undertake maintenance or extension activity. A less-damaging case is one in which testing uncovers the defects they unwittingly introduced due to the defective documentation. But if the defects aren’t caught in testing, and if those defects somehow find their way into production, the revenue or liability impact can be substantial, and it can vary from instance to instance of the technical debt in question. These effects are all forms of MICs.

So MICs can vary almost on an instance-by-instance basis. Or they might be constant across instances. It’s difficult to say. But the easy assumption—that MICs are the same for all instances of a given class of technical debt—the easy assumption is probably incorrect.

References

[CBS News 2013] CBS News and the Associated Press. “Thousands of U.S. bridges vulnerable to collapse,” May 25, 2013.

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.

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.

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.

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.

The common understanding of interest on financial debts 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.

Share this:

Few senior management teams would seriously consider making decisions about the use of financial instruments without first developing careful estimates of their effects on revenue and expenses. In most enterprises, there is an impressive array of tools, historical data, and skilled financial professionals to support those who devise or specify financial instruments for use in financing the enterprise. Yet few organizations invest at similar levels to support those who make estimates of the MICs involved in undertaking engineering efforts. A similar deficit of resources affects those who make estimates of the effects on revenue due to carrying technical debt.

A composite satellite view of Antarctica. Composite by Dave Pape using NASA’s Blue Marble data set. Exploring unknown territory, as Amundsen did in 1911-12, is far more difficult and far riskier than exploring mapped territory. For this same reason, managing technical debt is likely to be more successful when we have even minimal capability for estimating the MICs associated with carrying or retiring technical debt. Courtesy Wikimedia Commons.

This resource shortage has starkly negative effects, because of the inherent difficulties associated with projecting the effects of both carrying and retiring technical debt.

Although there can be a cost associated with carrying technical debt—I call them MICs—the cost can fluctuate dramatically depending on a range of factors, such as the kind of work underway on the asset that carries the debt; how customers are affected and what they’re doing at any given time; the difficulty of researching engineering problems arising from the debt; loss of revenue due to debt-related delays in reaching the market; loss of sales due to semi-catastrophic failures in customer demonstrations; and much more. In short, the MICs are often unpredictable [Allman 2012].

Moreover, most of the research into the effects of carrying or retiring technical debt has focused on engineering activity, and specifically, software engineering activity [MacCormack 2016][Kamei 2016]. Effects on other activities—marketing, sales, regulatory compliance, to name a few—are, by comparison, largely unstudied. And in many cases, the effects on these other activities are the most significant.

Consider first the effect of technical debt on enterprise expenses. The kind of maintenance and enhancement work performed on a set of assets bearing technical debt can determine the extent to which productivity is depressed, in turn affecting the MICs. In many cases, projecting future MICs associated with any given class of technical debt can be difficult because we might not know with sufficient certainty what projects will be undertaken in the intermediate term or long term future, and what kind of work those projects will undertake. Even when we do know these things, the level of involvement with instances of particular classes of technical debt can be difficult to project with a degree of certainty consistent with most other estimates.

Turning to revenue, for most organizations, the picture is also bleak. Because some classes of technical debt cannot be retired incrementally, attempts to retire them can have significant impact on operations and revenue. Research in this area is even more limited than in the area of effects on productivity.

Projecting MICs with useful accuracy would be a valuable capability. Making MICs more predictable would require systematically gathering data and building expertise for projecting MICs for your enterprise. That problem is more tractable than the more general problem of projecting MICs absent specific knowledge of enterprise characteristics.

An enterprise-specific MICs projection capability could elevate the quality of decisions regarding resource allocation for projects of all kinds, including technical debt retirement projects. Policymakers can play an important advocacy role in establishing such a capability.

References

[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.

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.

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.

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.

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.

The common understanding of interest on financial debts 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.

Share this:

A common assumption vis-à-vis technical debt is that its productivity-depressing and velocity-reducing effects, usually regarded as interest on the technical debt, can be modeled as relatively constant over time. In practice, the magnitude of these effects can vary dramatically with time, and that variation provides planners valuable insight and flexibility.

30-year average fixed mortgage rates in the United States, 2012-2017, in %. Over this five year period, although the rate did fluctuate, it did so in a narrow range of 3.3% to just over 4.5%. When we speak of “interest,” we tend to evoke an impression of relative stability, even when we’re speaking of technical debt, where MICs can vary from 0 to well above MPrin in any given time period. That’s one thing that makes the term “interest” so misleading in the context of technical debt. Data provided by U.S. Federal Reserve Bank of St. Louis [Federal Reserve 2017].As an example of this assumption, Buschmann states that the longer we wait to retire technical debt in design and code, the larger the amount of interest [Buschmann 2011]. This presumes constant, or at least non-negative, metaphorical interest charges, an assumption that might be valid for some situations, but which is not universally applicable. Those projects that entail maintenance or extension of parts of the system that don’t manifest a specific class of technical debt, and which don’t depend on elements that do manifest it, are much less likely to incur the MICs associated with that debt. So with respect to any particular class of technical debt, during time periods in which no projects incur MICs, the interest accrued in those periods can be zero. In other time periods, the interest accrued on account of that same class of technical debt could be very high indeed.

A capacity for projecting MICs associated with a particular class of technical debt can be useful to planners as they work out schedules for maintenance projects, development projects, and technical debt retirement projects. Technical debt retirement projects are also subject to MICs, including from classes of technical debt other than the debt they’re retiring.

Analogous to the functioning of governance boards, a technical debt resources board could provide resources for evaluating assessments of likely MICs for maintenance projects, development projects, and technical debt retirement projects. Decision makers could use these assessments when they set priorities for these various efforts. I’ll say more about technical debt resources boards in future posts.

References

[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.

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.

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.

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.

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.

The common understanding of interest on financial debts 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.

Share this:

Using the term interest to refer to the metaphorical interest charges that are associated with a technical debt is risky. The risk arises from confusing the properties of financial interest with the properties of the metaphorical interest charges on technical debt. Using an alternative term that makes the metaphor obvious can limit this risk. One such term is metaphorical interest charges, or for convenience, MICs.

Loose change. The MICs on technical debt are accumulated in two ways: (a) as “loose change,” namely, small bits of lost time, delays, and depressed productivity; and (b) as major blows to enterprise vitality in the form of lost revenue, delayed revenue, and missed market opportunities. Hard to say which category does more damage.

MICs aren’t interest charges in the financial sense; rather, the MICs of a technical debt represent the total of reduced revenue, incidental opportunity costs, and increased costs of all kinds borne by the enterprise as a consequence of carrying that technical debt. (Actually, now that I think of it, MICs can include financial interest charges if we find it necessary to borrow money as a consequence of carrying 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.

Briefly, MICs are variable and often unpredictable [Allman 2012]. MICs differ from interest charges on financial debt for at least six reasons. For any particular class of technical debt:

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.

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.

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.

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.

The common understanding of interest on financial debts 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.

Share this:

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

References

[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.

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.

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.

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.

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.

Share this:

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. 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-shoringBut 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.

References

[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.

Related posts

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.

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.

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.

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.

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

Share this:

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

References

[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.

Related posts

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.

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.

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.

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.

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

Share this:

The MPrin of technical debt incurred 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 performing only some of the work needed as a consequence of the upgrade, then the MPrin is the total cost of performing the work we deferred. If we incur the debt by deferring the upgrade, then the conventional definition of the MPrin is the cost of the upgrade plus the cost of any work necessitated by the upgrade, but not performed.

An aisle in the stacks of a library. 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 [Boss 2011]. It’s a big job.

In this latter instance, MPrin can increase over time if some of the work performed in the environment of the obsolete platform component, but subsequent to deferring the upgrade, must later be repeated after the upgrade is ultimately installed. This situation can be even worse if the work performed in the environment of the obsolete platform component fails after the upgrade, but the maintainers do not recognize the reason for the failure. In that case, an investigative effort is required first, to determine the cause of the failure. These additional costs are actually part of the debt retirement effort for the debt incurred by deferring the upgrade, but they’re usually accounted for — mistakenly — as routine operational expense.

References

[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.

Related posts

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.

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.

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.

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.

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

Share this:

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

References

[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.

Related posts

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.

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.

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.

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.

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

Share this:

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.

Share this:

Posts navigation

Contact me on social media:

Reference posts

A collection of definitions of terms as we use them in this blog, with links to longer discussions of each term. Along with each definition is a link to a post that discusses that term in more detail. Read more…

Welcome to Technical Debt for Policymakers. What you’ll find here are resources, insights, and conversations of interest to policymakers who are concerned with managing technical debt within their organizations. Read more…

When retiring one kind of technical debt from an asset, auxiliary technical debt is any other kind of technical debt in the asset. It can be tempting to try to retire auxiliary technical debt too. Sometimes that’s wise, but it can lead to scope creep. Rules of engagement can control this temptation. [More]

To retire technical debt, we need to know where it is. And if service disruptions are necessary, we need to know who will be affected. Here’s a survey of some of the issues, and suggestions for resolving them. [More]

For some assets, we can’t allow debt to persist, and we can’t afford replacements. We must retire the debt. This post begins exploring what it takes to design projects to retire technical debt in irreplaceable assets. [More]

By carefully observing what happens when we actually try to retire some kinds of technical debt, we can better understand the degree of the degree of wickedness of the effort. That understanding helps manage risk in technical debt retirement projects, reducing costs and speeding execution. [More]