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. The policy implications of the properties of technical debt arise from three fundamental differences between technical debt and financial debt.
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 at 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. Technical debt is everywhere.The policy implications of these properties of MPrin can be profound. First, spontaneous change in MPrin implies a need for investments in market and technological intelligence. The intelligence of greatest value focuses specifically on potential effects on technical debt. Second, existing technical debt can lead to creating new instances of that debt or other debts. We can limit this “contagion” if we know 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 might be unwise. 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.
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.
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.
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.
Recall that our definition of the metaphorical principal of a technical debt (MPrin) at a given time is the cost of retiring the debt at that time. This cost can change with time. For example, due to ongoing maintenance and enhancements, the part of the asset in which the debt is embedded might become rather more complicated or constrained than it was earlier. That increased complexity can increase MPrin. This can happen even if the elements that comprise the debt itself have remained unchanged.
Moreover, the MPrin of any extensions to the asset in question, or to other assets, might also change. Those assets that use services provided by a subsystem manifesting the debt might also require alteration at debt retirement time. Untangling the debt from its surroundings, making necessary modifications, and testing the result, can be a delicate and complex process. The process might actually cost more at debt retirement time than whatever was saved when the debt was incurred.
An example of MPrin changing spontaneously
On the other hand, in some circumstances, the cost of retiring the debt can decrease over time. Consider the following fictitious example.
A high pressure sodium streetlight at dusk. Photo (cc) Famartin courtesy Wikimedia Commons.
Zion is a small city of 110,000 that’s struggling with two problems related to street lighting. Its current streetlights use High-Pressure Sodium (HPS) lights. HPS lights use almost twice as much energy as do the newer LED streetlights for the same level of illumination. Zion’s second problem is that the existing streetlights provide only one level of illumination throughout the city. This is causing a stream of complaints from many residents who have concerns about street lighting spilling onto their property at night. The bright light interferes with the sleep patterns of people and their pets.
Both of these problems have technical solutions that became available after the current HPS lights were installed. That’s why we can view them as arising from technical debt. Zion had investigated resolving the light pollution problem, but couldn’t find an affordable solution. Time passed. When LED streetlights became widely available, Zion investigated retiring its HPS lights. They found an LED lighting system that was dimmable on a block-by-block basis using a wireless control system. By retiring the technical debt associated with the HPS lights, Zion was able to afford retiring the technical debt associated with its un-dimmable lighting system.
Zion was able to afford to retire both forms of technical debt at once because of the way they interacted, even though retiring them one at a time would have been too expensive.
This example shows that the MPrin of a technical debt can vary widely, depending on the assets involved, and on what other debts they carry. Such variation is far more common in the realm of technical debt than it is in the world of financial debt.
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.
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.
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.
The “metaphorical principal” amount of a technical debt isn’t like the principal amount of a financial debt. In fact, the two are so different that policymakers can make real trouble for their organizations if they fail to take the differences into account.
Accomac Debtors’ Prison in Accomac, Virginia. After construction in 1783 it served as a jailer’s house. It served as a debtors’ prison from 1824 to 1849. Debtors could regain freedom by working to earn their keep and retire their debts, if they couldn’t pay them off. Today, bankruptcy laws facilitate property seizures to retire debts. Requiring an organization’s engineering functions to fund technical debt retirement through expense budgets is analogous to debtors’ prison. Photo (cc) Ser Amantio di Nicolao, courtesy Wikimedia Commons.In finance, the principal amount of a loan at the time of origination is the amount the creditor transfers to the debtor. Over time, as the debtor makes payments according to the terms of the loan agreement, the principal either remains constant or declines gradually. The terms of the loan agreement determine the actual remaining principal at any given time. This is the layperson’s definition. It’s the basis of the association people make with respect to the metaphorical principal amount of a technical debt.
Consequences of the layperson’s definition of debt
For technical debt management, the associations most people make with the debt concept are unfortunate. For example, using the term principal to refer to the metaphorical principal of a technical debt creates risk. The risk arises because the metaphorical principal behaves very differently from financial principal. Financial principal is typically constant or slowly declining. The metaphorical principal of technical debt can exhibit sudden and dramatic fluctuations. These confusions arise because of unintended associations of the technical debt metaphor.
Why I use the term MPrin instead of principal
We need a way to limit the risk of confusing the metaphorical principal of technical debt with the principal of a financial debt. The term metaphorical principal is so inconvenient that I prefer MPrin.
Most people don’t distinguish the initial principal amount of a technical debt and MPrin. But some have addressed it [Seaman 2013]. For example, Avgeriou et al. define the initial principal of a particular class of technical debt as the savings realized by incurring the debt [Avgeriou 2016]. They define the current principal as the resources required to deploy a different or better solution at the current time.
The initial principal concept of Avgeriou et al. is what I call in this blog the MPrin at the time the debt is incurred, or initial MPrin. Although the initial MPrin does have some value for decision makers at the time the debt is incurred, it’s most valuable when deciding whether to incur the debt, if, indeed, one has an opportunity to make such a decision. However, once the organization incurs the debt, the current MPrin at debt retirement time is what matters; initial MPrin becomes irrelevant.
Last words
Policymakers must keep clearly in mind that the MPrin of a given kind of technical debt is the total cost of retiring that debt, at the time it is retired, including all cost sources.
We’ll have a look at the policy implications of the properties of MPrin next time.
References
[Avgeriou 2016] Paris Avgeriou, Philippe Kruchten, Ipek Ozkaya, and Carolyn Seaman, eds. “Managing Technical Debt in Software Engineering,” Dagstuhl Reports, 6:4, 110–138, 2016.
[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.
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.
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.
Flooding from Hurricane Katrina in New Orleans, 2005. The forces of Nature can overtop or undermine any levee humans can build. So it is with technology. Organizational policy and politics can overcome or undermine any technology humans can devise to attain mastery over technical debt. To master technical debt, technology isn’t enough—we must also deal with policy and politics.
Improving organizational effectiveness in technical debt management—or avoiding incurring new technical debt—should create significant savings and competitive advantages. These benefits arise from reductions in metaphorical interest charges (MICs) that result from retiring technical debt. But these benefits become available only if engineering capacity increases relative to the total debt-related workload. After the technical debt management program is in place, if the balance between engineering resources and debt-related workload becomes more favorable, then organizational effectiveness can improve. But if the balance becomes less favorable, as a result of reductions in engineering resources, organizational effectiveness won’t improve, even at lower levels of technical debt.
Unfortunately, some organizations adopt advanced technical debt management practices while reducing engineering capacity. If reductions are dramatic enough, engineering effectiveness is no better than it was before initiating the technical debt management program. The reason for this is that the engineering process isn’t the sole cause of technical debt. Improving the engineering process to eliminate technical causes of technical debt leaves nontechnical causes in place. That’s why technological solutions to the technical debt management problem might not produce benefits in organizational effectiveness and agility.
The focus of technical debt research has been technology
The focus of research in technical debt management has been on technology—recognition of technical debt, its measurement, representation, retirement, and so on. Progress on improving the engineering process has been significant, especially in software engineering, where a clear “research roadmap” has appeared [Izurieta 2017]. Effective tools for automating or partially automating technical debt detection and retirement will be widely available and very generally effective in the not-too-distant future, at least for software. But progress has transcended debt detection and retirement. Avoiding technical debt formation to the extent possible is much preferable, and in some contexts, it’s practical even today, as Trumler and Paulisch suggest [Trumler 2016].
Such developments might or might not have much impact on the limiting the effects of carrying technical debt. Given the necessary resources, engineering organizations could retire much of the technical debt now extant. That is, the will and the capacity to invest in debt retirement determines debt retirement rates. Currently, the levels of will and capacity for such activity are insufficient. But if new methods for managing technical debt become available, one might wonder whether organizations will apply resources sufficient to ensure that they actually experience a reduction in the limiting effects of technical debt.
Technological development isn’t enough
The open question is this: will technological developments alone give us control of the problem of technical debt? Perhaps not. Advancements in technical debt management do benefit organizations. But they could use that benefit to execute reductions in engineering staffing. If they do, they could divert savings to other parts of the enterprise. That would allow technical debt to remain at reduced levels that could still compromise the effectiveness of that reduced engineering staff.
For example, research has shown that schedule pressure contributes to technical debt formation and persistence. Suppose that the engineering groups of an organization become more adept at managing and preventing technical debt. Suppose further that the organization’s marketing and sales groups don’t improve their own intelligence and planning processes. Then Marketing might demand new capabilities with ever shorter timelines. That could lead to increased schedule pressure for the engineering groups. Then the enterprise might not benefit from the new technical debt management capabilities, even though the burden of technical debt has been reduced.
Until we have evidence of significant change in the behavior of non-technologists—or even acknowledgment that their behavior contributes to debt formation—we can expect the effects of nontechnical causes of technical debt to persist, and possibly even to grow.
This blog focuses on the nontechnical etiology of technical debt formation and persistence, and approaches for managing it. Watch this space.
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.
[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.
[Trumler 2016] Wolfang Trumler and Frances Paulisch. “How ‘Specification by Example’ and Test-driven Development Help to Avoid Technical Debt,” IEEE 8th International Workshop on Managing Technical Debt. IEEE Computer Society, 1-8, 2016. doi:10.1109/MTD.2016.10
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.
Shown here are servers like the ones that made this page available to you. Cybersecurity is concerned with defending servers like these, among others.
Policymakers have in mind the best interests of the entire enterprise. They need a definition of technical debt that’s neutral relative to its causes and manifestations. Defining technical debt in terms of what caused it or where it lies in the enterprise could compromise that necessary neutrality.
That neutrality is important because it enables us to recognize technical debt in whatever form it takes. For example, suppose enterprise policy assumes that technical debt lies only in software. And suppose that the root causes of some instances of technical debt are new threats in the cybersecurity environment that render obsolete our cyberdefenses. Then enterprise policy vis-à-vis technical debt is likely to be ineffective. It might lead to decision makers focusing too much attention on the software development process and too little attention on the cybersecurity and threat intelligence processes.
A definition that’s useful for guiding policy
Here’s a cause-neutral and manifestation-neutral definition of technical debt. It’s what I call the policymaker’s definition [Brenner 2017a]:
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. It is therefore something we would 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.
Extending the technical debt metaphor just a bit, people often talk about the principal and the interest charges associated with a technical debt. These ideas are analogous to the principal and interest charges associated with a financial debt. They’re convenient concepts, but the parallels between finance and technology aren’t real, and that’s where the trouble lies. Read more
An important extension beyond conventional definitions
There’s one other generalization contained in this definition of technical debt that differs from most other definitions. It’s in the phrase “or missing from.” Our policymaker’s definition doesn’t require that the technical debt item actually exist. That is, the absence of something can constitute technical debt. My favorite example is one due to Ken Pugh, who defines acceptance test debt as “…the nonexistence or nonautomation of acceptance tests.” [Pugh 2010] If we want to include all sources of reduced organizational agility or unnecessary operating expense arising from technical debt, our definition must also address non-existence issues like those Pugh has identified.
The definition above is workable for systems of all kinds. Consider two examples of “hardware”:
But the definition also applies to anything that takes a technological form, including business plans, legislation, procedures, and microprocessor designs—almost anything.
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.
[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.
[Trumler 2016] Wolfang Trumler and Frances Paulisch. “How ‘Specification by Example’ and Test-driven Development Help to Avoid Technical Debt,” IEEE 8th International Workshop on Managing Technical Debt. IEEE Computer Society, 1-8, 2016. doi:10.1109/MTD.2016.10
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.
Policy is one of those concepts that we rarely define explicitly because we believe we all agree on what it means. But in this context, we must take some care to be certain that we do in fact agree. In this blog, policy is the set of general guidelines people follow when making decisions and taking action.
Acela Express rounds a curve in Connecticut. Shown is the trailing power car of a southbound Acela Express and the front of a northbound Metro-North railcar.
Most definitions of technical debt require that the asset bearing the debt be software. From the policymaker’s perspective, this requirement is rather limiting. So for the purposes of this blog, I define technical debt as any property of a technological asset that we would like to revise, replace, or create, and which limits the ability of the enterprise to gain or maintain a market dominance. (See “A policymaker’s definition of technical debt.”)
An example from the railroad industry
In the United States, the highest-speed rail line is Acela Express. Acela travels in the northeast corridor between Boston and Washington, D.C. Parts of the right-of-way, track, and catenary it uses are from legacy lower-velocity applications. That’s why Acela trains cannot operate at their highest possible speed [Maloney 2000]. On the 231-mile section from Boston to New York’s Penn Station, Acela achieves an average speed of only 63 mph (101 km/h), even though the trains can operate safely on straight track at 150 mph (240 km/h). Yet, Acela still manages to capture a 54% share of the total air and rail market between these two cities
How Acela’s technical debt slows its trains
That 54% share might be higher still if not for technical debt. To compensate for centrifugal forces as Acela rounds curves, its passenger cars tilt their passenger spaces. The tilt enables the train to round the curves at higher speeds than would otherwise be comfortable for passengers. In effect, the cars “lean into” the curves, just as a running athlete leans when rounding a curve. Although the cars could tilt by as much as 6.8º, the adjacent set of tracks is too close to permit this without risk of collision with trains on those tracks. The maximum permissible tilt in this system is therefore 4.2º, which reduces the maximum speed consistent with passenger comfort that the trains can attain on curves. The technical debt in the tracks Acela uses thus prevents Acela from offering a service that would be more competitive with alternative transport modes, especially airlines.
Last words
In August 2016, Amtrak announced that it will be upgrading its trainsets and tracks to exploit new technologies, including active tilt technologies. All existing trainsets are due to be replaced in 2021-22.
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.
[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.
[Trumler 2016] Wolfang Trumler and Frances Paulisch. “How ‘Specification by Example’ and Test-driven Development Help to Avoid Technical Debt,” IEEE 8th International Workshop on Managing Technical Debt. IEEE Computer Society, 1-8, 2016. doi:10.1109/MTD.2016.10
This case illustrates how a decision to incur technical debt in one part of an organization can burden other parts of the organization with the metaphorical interest charges on that debt. To gain effective control of technical debt, it’s probably necessary to hold accountable those who make the decisions that lead to incurring new debt.
This case illustrates the importance of recognizing as technical debt any artifact whose condition or absence contributes to a loss of organizational effectiveness or agility. It describes a situation related to software development, and which some would argue isn’t actually technical debt.
This case involves deferring a platform upgrade for SharePoint sites. It illustrates the importance of the policymaker’s view of technical debt, as compared to the view that restricts technical debt to the engineering or IT functions.
Here’s an example of using the technical debt metaphor in civil engineering. In this case, it helps us understand why, in some cases, leaving some technical debt in place can be a better choice than retiring it.
The ghost ramps of highway I-695 in Somerville, Massachusetts. Photo (cc) Nick Allen.
Interstate 695 was planned in 1955 as an “inner belt” circumferential route in Boston and adjacent towns. When cancelled in 1971, construction had already begun. The cancellation thus resulted in an incomplete implementation.
Newly constructed roads and mass transit now use the rights of way that were the original paths for I-695. Some never-used structures remain to this day, including a “ghost ramp” in Somerville that would have connected I-695 to I-93. Because this ramp is a mere stub that begins on an elevated stretch of I-93 and ends in mid-air, barriers across the stub entrance prevent accidental use. The ghost ramp constitutes technical debt because it’s an incomplete implementation. Google satellite view
For safety reasons, regular inspections, maintenance, and insurance are necessary for the ghost ramp. But it provides no utility and serves no civic purpose. Because the cost of retiring this technical debt—namely, demolition costs—would likely exceed the present value of the lifetime costs of inspection, maintenance, and insurance, the ghost ramp remains.
Sometimes, the best way to deal with technical debt is to leave it in place.
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.
[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.
[Trumler 2016] Wolfang Trumler and Frances Paulisch. “How ‘Specification by Example’ and Test-driven Development Help to Avoid Technical Debt,” IEEE 8th International Workshop on Managing Technical Debt. IEEE Computer Society, 1-8, 2016. doi:10.1109/MTD.2016.10
This case illustrates how a decision to incur technical debt in one part of an organization can burden other parts of the organization with the metaphorical interest charges on that debt. To gain effective control of technical debt, it’s probably necessary to hold accountable those who make the decisions that lead to incurring new debt.
This case illustrates the importance of recognizing as technical debt any artifact whose condition or absence contributes to a loss of organizational effectiveness or agility. It describes a situation related to software development, and which some would argue isn’t actually technical debt.
This case involves deferring a platform upgrade for SharePoint sites. It illustrates the importance of the policymaker’s view of technical debt, as compared to the view that restricts technical debt to the engineering or IT functions.
Here’s an example of using the technical debt metaphor to think about how elements of a hardware asset can limit the ability of the enterprise to attain and maintain market leadership. The asset in this example is the trackbed of Amtrak’s Acela Express.
A metaphor is a figure of speech that references one concept, object, or action, by identifying it with another. In metaphors, that identification of one concept with another isn’t literally accurate. Metaphors help us understand and experience one thing, with which we might be unfamiliar, in terms of another, with which we’re more familiar [Lakoff 1980]. Understanding the structure of metaphors helps us understand how to use them—and mitigate the risks that arise when we do use them.
For example, consider the statement,“my son’s room is a war zone.” As a metaphor, it identifies my son’s room as a war zone, when it isn’t literally a war zone. We mean that his room is messy and disorganized. We don’t mean to imply that military ordnance or troops are involved. More examples:
True friends stab you in the front. — Oscar Wilde
A squirrel is just a rat in a cuter outfit. — “Carrie Bradshaw,” played by Sarah Jessica Parker in Sex in the City
A bank is a place where they lend you an umbrella in fair weather and ask for it back when it begins to rain. — variously attributed to Robert Frost, Mark Twain, and others
In these examples, Oscar Wilde isn’t saying that friends actually stab anyone. Nor is “Carrie Bradshaw” saying that squirrels are rats, or that they wear clothing. And Frost or Twain isn’t saying that banks actually lend umbrellas. Nevertheless, these three statements do literally imply stabbings, squirrel clothing, and umbrella distribution. These metaphors make their points by being literally inaccurate. The literal but untrue assertion is the hallmark of the metaphor.
Unintended associations: why using metaphors can be risky
The fundamental structure of metaphors is “A is B.” Borrowing terminology from cognitive linguistics, A is the target of the metaphor and B is its source. Thus, the squirrel is the target; the rat in a cuter outfit is the source. The bank is the target; the perfidious umbrella lender is the source. For the technical debt metaphor, the needed technical work is the target; financial debt is the source. Metaphors aid us by applying what we understand well in the domain of the source. The metaphor applies that to what we understand less well in the domain of the target.
Definition
A metaphor is a figure of speech used to convey understanding of one concept, object, or action by identifying it with another that is well understood, even though the identification is not literally accurate. The well-understood concept is called the source. The less-well-understood concept is called the target. The metaphor is thus a statement that “<Target> is <Source>.” Although the identification of target with source is literally invalid, it provides a means of understanding some aspects of the target in terms of some of the properties or behavior of the source.
Because metaphors compel our minds to accept the identification between source and target in toto, they can cause us to make errors of thought. Those errors create risks for the enterprise as we attempt to manage technical debt. The risk arises because we begin to regard technical debt as a form of financial debt, when in reality it is not. The risk of misidentification is acceptable if we understand it and manage it properly. But that risk is often unrecognized, and therefore it remains unmitigated. A significant source of this risk is our inability to control which attributes of the metaphor’s source the reader or listener chooses to associate with the metaphor’s target. We can call this phenomenon unintended association.
Some of the unintended associations of the technical debt metaphor cause real problems for organizations as they try to manage their technical debt. We explore the unintended associations of the technical debt metaphor 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.
[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.
[Trumler 2016] Wolfang Trumler and Frances Paulisch. “How ‘Specification by Example’ and Test-driven Development Help to Avoid Technical Debt,” IEEE 8th International Workshop on Managing Technical Debt. IEEE Computer Society, 1-8, 2016. doi:10.1109/MTD.2016.10
Because metaphors compel our minds to accept the identification between source and target in toto, they can cause us to make errors of thought. Those errors create risks for the enterprise as we attempt to manage technical debt. The risk arises because we begin to regard technical debt as a form of financial debt, when in reality it is not.
The technical debt metaphor is both powerful and perilous. Its power lies in its ability to communicate the concept that some technological assets regarded as operational might—and probably do—need further attention. The peril arises when we think of this metaphorical technical debt as if it were a financial debt.
Ward Cunningham, who coined the technical debt metaphor. Photo (cc) Carrigg Photography.
Ward Cunningham coined the technical debt metaphor in the context of developing a software asset [Cunningham 1992] [Cunningham 2011]. He observed that when the development process leads to new learning, re-executing the development project—or parts of the project—could lead to a better result. For this reason, among others, newly developed operational software assets can contain or depend upon artifacts he regarded as technical debt. In hindsight, the developers recognize they could remove these artifacts altogether. Or they could replace them with more elegant, effective, or appropriate forms. In this way, they could enhance maintainability, defensibility, and extensibility. To deploy the asset in pre-hindsight condition would entail an obligation to return to it in the future to implement the improvements. That obligation is Cunningham’s conception of the asset’s technical debt.
Fowler’s technical debt quadrant. Intentionality is the vertical axis; Wisdom is horizontal.
In the decades since Cunningham coined the term, the meaning of technical debt has evolved. It now includes much more than Cunningham’s original concept. Martin Fowler developed a 2×2 matrix (which I interpret as Intentionality x Wisdom) that describes four different pathways that lead to technical debt creation. Cunningham’s concept corresponds to what Martin Fowler describes as, “now we know how we should have done it” [Fowler 2009].
At a conference in Dagstuhl, Germany (“Managing Technical Debt in Software Engineering”) in 2016, leading experts in software technical debt research developed a verbal definition of technical debt for software-intensive systems [Avgeriou 2016]:
In software-intensive systems, technical debt is a collection of design or implementation constructs that are expedient in the short term, but set up a technical context that can make future changes more costly or impossible. Technical debt presents an actual or contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability.
With the definition of technical debt enlarged in this way, software engineers can focus on instances of software technical debt that reduce enterprise productivity and agility. But is this definition sufficient as a foundation for enterprise policy? I explore that question in “A policymaker’s definition of technical debt.”
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.
[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.
[Trumler 2016] Wolfang Trumler and Frances Paulisch. “How ‘Specification by Example’ and Test-driven Development Help to Avoid Technical Debt,” IEEE 8th International Workshop on Managing Technical Debt. IEEE Computer Society, 1-8, 2016. doi:10.1109/MTD.2016.10
DuBrin defines policies as “… general guidelines to follow when making decisions and taking action” [DuBrin 2016]. Some policies are written, some are unwritten. Some have names or identifiers, some don’t. For organizations seeking to gain control of technical debt, written policies are probably a good idea, for two reasons:
Many people affected by technical debt policies are probably unfamiliar with the technical debt concept. A written policy is more likely to be communicated uniformly to everyone.
The effort spent devising a written policy is likely to surface ambiguities, confusions, and differing needs. That’s one of the benefits of devising written policies. Resolving these issues during the policy formation process is better for the organization than resolving them during the deployment process.
A useful policy is clear. It uses terminology that’s simple and well-defined.
Properties of technical debt policy
Achieving these goals for technical debt policy formulation can present special problems. Much of the audience for the policy is unaware or incredulous of the connection between their own behavior and technical debt formation.
Specifically:
The policy must address an issue—technical debt—that has mainly technological manifestations
The policy must provide guidance for people as they make choices
Some of the choices that people make will produce technological manifestations
The connections between the choices and the technological manifestations can be obscure, especially
when the choices don’t appear to be technical
Some technical debt arises from phenomena unrelated to behavior of anyone within the organization
Said differently, technical debt policy must confront four issues:
Some people whose behavior we must modify are unaware of the consequences of their behavior
Some of those same people strongly believe that the technical debt problem results from malpractice by others
Current incentive structures play an important role in technical debt formation
Some technical debt arises from phenomena external to the organization
Effective technical debt policy must therefore include these elements:
An education component to help people see the connection between their choices and technical debt formation
A situational awareness component to alert the organization to internal and external developments that could cause technical debt formation
A means of allocating resources to technical debt management that holds accountable the business units whose actions contributed to technical debt formation
A means of committing future resources to technical debt retirement
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.
[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.
[Trumler 2016] Wolfang Trumler and Frances Paulisch. “How ‘Specification by Example’ and Test-driven Development Help to Avoid Technical Debt,” IEEE 8th International Workshop on Managing Technical Debt. IEEE Computer Society, 1-8, 2016. doi:10.1109/MTD.2016.10
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.
The policymaker's definition of technical debt is neutral relative to its causes and manifestations. Its focus is what technical debt costs if we leave it in place, what advantages it offers, and what we would need to do if we decide to retire it.
