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 dominant market leadership position.
Consider an example from the railroad industry. In the United States, the highest-speed rail line is Acela Express, which travels in the northeast corridor between Boston and Washington, D.C. Parts of the right-of-way, track, and catenary it uses were not originally designed for this application, and therefore 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.
That 54% share might be higher still if not for technical debt. To compensate for centrifugal forces as Acela Express rounds curves, its passenger cars are able to tilt the passenger spaces to enable 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 making a sudden change of direction. Although the cars were designed to be able to 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 tilt is therefore set at 4.2º, which, in turn, reduces the maximum speed consistent with passenger comfort that the trains can attain on curves. The technical debt manifested in the tracks Acela Express uses thus prevents it from offering a service that would be more competitive with alternative transport modes, especially airlines.
Note: 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
[Maloney 2000] Brenna Maloney and Don Phillips. “All Aboard AMTRAK’s Acela,” The Washington Post, November 30, 2000.
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 is not 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 it was cancelled in 1971, construction had already begun. Rights of way that had been cleared have since been reused for roads and mass transit, but some never-used structures remain to this day, including a “ghost ramp” in Somerville that would have connected I-695 to I-93. This ramp, which is a mere stub that begins on an elevated stretch of I-93 and ends in mid-air, and which is blocked off to prevent use, constitutes technical debt in the form of incomplete implementation. Google satellite view
For safety reasons, the ghost ramp must be regularly inspected, maintained, and insured, but it provides no utility and it is not used for any 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
[Maloney 2000] Brenna Maloney and Don Phillips. “All Aboard AMTRAK’s Acela,” The Washington Post, November 30, 2000.
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 is not 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, when that identification is not literally accurate. Metaphors help us understand and experience one thing, with which we might be unfamiliar, in terms of another, with which we are more familiar [Lakoff 1980].
For example, “my son’s room is a war zone,” identifies my son’s room as a war zone, when it is not literally a war zone. We mean by this that his room might be messy and disorganized, but we do not 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 is not saying that friends actually stab anyone; “Carrie Bradshaw” is not saying that squirrels are rats, or that they wear clothing; and Frost or Twain are not 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.
The fundamental structure of metaphors is “A is B.” Borrowing terminology from cognitive linguistics, A, the main entity referenced, is called the target of the metaphor; B, the entity alluded to, is called the 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 obligation or financial debt is the source. Metaphors serve to aid us in applying what we understand well in the domain of the source, 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. This misidentification is an acceptable risk, if it is properly managed and understood, 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
[Lakoff 1980] George Lakoff and Mark Johnson. Metaphors We Live By. Chicago: The University of Chicago Press, 1980.
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, who coined the technical debt metaphor in the context of developing a software asset [Cunningham 1992] [Cunningham 2011], 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, embody, or depend upon artifacts that, in hindsight, the developers recognize could be removed altogether, or could be replaced by more elegant, effective, or appropriate forms that can 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 revealed by that hindsight. 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 to include much more than Cunningham’s original concept. Martin Fowler developed a 2×2 matrix (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.
DuBrin define 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 varying needs. 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 is simple and well defined.
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.
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.
Policymakers need a definition of technical debt that’s neutral relative to its causes and manifestations, because defining technical debt in terms of what caused it or where it lies in the enterprise could compromise that necessary neutrality.
As we 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. Organizational policy is the framework of principles that guide policymakers, decision makers, and everyone in the organization as they carry out their responsibilities.
Some organizational policies that do not even mention technical debt can affect the way the organization manages technical debt. For this reason, all policymakers are potentially involved in formulating policy that affects the ability of the organization to manage 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.
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.
Policymakers need a definition of technical debt that’s neutral relative to its causes and manifestations, because defining technical debt in terms of what caused it or where it lies in the enterprise could compromise that necessary neutrality.
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.
Background
During the troubles following release of UGI’s StrawIntoGold 1.0 product, the Help Desk operated by UGI’s Customer Service Department was inundated with calls for assistance. Customer Service alerted Engineering, which provided an explanation and an estimated repair date for the customer service representatives to pass on to callers, but in the crush and panic, neither Engineering management nor Customer Service management provided a script for the representatives to use when the calls came in. Consequently, calls took approximately 15% longer to handle than they would have if a carefully worded script had been available. Further, the message conveyed to customers was not always clear or consistent, which resulted in some customers calling again with the same issue.
Discussion
The decision not to provide customer service representatives with a script can be viewed as incurring a technical debt. The extra time handling calls, the extra calls that resulted from the absence of a script, and even a few lost customers, can be viewed as the metaphorical interest charges on that technical debt. Because of the singular nature of this incident, it’s doubtful that a script will ever be written, but if it were, the cost of doing so, and the cost of distributing it and training all customer service representatives would be the metaphorical principal of this technical debt.
The policymaker’s perspective
UGI doesn’t have a means of making those who incurred the debt accountable for the metaphorical interest charges on that debt. In this case, the Customer Service function incurs additional operating expenses because the Engineering and Customer Service, together, elected not to develop a script for the customer service representatives.
Another component of the metaphorical interest charges is the total of lost sales, damage to UGI’s reputation, and possible loss of market share. Marketing could have stepped in to assist with limiting that damage, but because they viewed the problem as technical, they did not participate. A whole-enterprise perspective on managing the technical debt might have led to a collaboration between Engineering, Marketing, and Customer Support to build better relationships with the customers who were affected by the incident.
Accounting properly for the metaphorical interest charges associated with technical debt can lead to a better understanding of the effects 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.
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 is not 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.
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.
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 is not actually technical debt.
Background
One reason why growth has been so unbelievable at Unbelievable Growth, Inc., is the recent release of their new app for Android and iPhone, StrawIntoGold 1.0, which has an uncanny ability to predict the price movements of specific common stocks over the next 60 seconds. Some users had complained about the unresponsiveness of the user interface in release 1.0, which caused them to miss the 60-second window. Engineering did some quick work and shipped StrawIntoGold 1.1 to fix the problem. In their haste, they were unable to automate all testing, and 17 interns that were hired just for that release performed some critical tests manually to ensure that the problem had been fixed. Because those manual tests have not yet been automated, and because the interns have been let go, the engineers working on StrawIntoGold 2.0 are doing their own tests manually, which is reducing their productivity considerably. Release 2.0 is now three months late, so far, and the projected ship date is at least three months from now.
Discussion
We can regard the decision to ship release 1.1 without automating all tests as incurring a technical debt consisting of the tests that were not automated. Until that debt is retired, something analogous to interest charges are being paid, in the form of reduced engineering productivity, which raises the costs of producing the next release, and which also delays the revenue stream projected for StrawIntoGold 2.0. That causes a loss of revenue, which is another contribution to metaphorical interest charges on the outstanding technical debt. The metaphorical principal of the technical debt is the cost of implementing the automated testing facilities, including documentation and training for the engineers who will be using them.
The policymaker’s perspective
Some conventional views of technical debt do not regard the missing test automation facilities as technical debt, because they aren’t part of the product. For example, Kruchten, et. al. [Kruchten 2013], take the definition of technical debt to be restricted to items characterized as “direct system characteristics.”
But even among those who regard the missing tests as technical debt, and the depressed engineering productivity as a metaphorical interest charge on that debt, some would not regard the delayed revenue as a metaphorical interest charge.
From the policymaker’s perspective, any loss of organizational effectiveness attributable to the condition or absence of a technological artifact is potentially a metaphorical interest charge arising from the technical debt associated with that artifact.
It’s difficult for organizations to allocate resources to technical debt management unless they know the full costs associated with carrying 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.
[Kruchten 2013] Philippe Kruchten, Robert L. Nord, Ipek Ozkaya, and D. Falessi, “Technical debt: towards a crisper definition report on the 4th international workshop on managing technical debt.” ACM SIGSOFT Software Engineering Notes, 38:5, 51-54, 2013.
Includes a comment that testing debt is not technical debt. Includes a comment that technical debt is result of quick and dirty work.
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 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.
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.
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.
Background
File servers in a rack. Photo (cc) Abigor courtesy Wikimedia Commons.
Growth at the fictional company Unbelievable Growth, Inc. (UGI) has been so unbelievable that there is now a shortage of financial resources for migrating the last groups of SharePoint users from SharePoint 2010 to SharePoint 2013. Consequently, the CFO instructed IT to continue to support SharePoint 2010 for at least two more quarters. Meanwhile, the affected SharePoint users must continue to use SharePoint 2010. Someday, currently set for two quarters from now, IT and the users of SharePoint 2010 will be required to migrate to SharePoint 2013. Both IT and the users might need to expend resources to keep the SharePoint 2010 site operational. Users who make enhancements to their SharePoint 2010 sites will need to migrate that work to the SharePoint 2013 site, and that might require some rework that would have been unnecessary if the migration had not been deferred.
Discussion
We can regard as a debt UGI’s decision to defer the SharePoint migration. Because it isn’t a financial obligation, we call it a technical debt. UGI must retire that technical debt two quarters from now, when they finally execute the migration from SharePoint 2010 to SharePoint 2013. We can regard the cost of the final migration as the (metaphorical) principal of the technical debt. In the meantime, IT and the users must do some work that might have been unnecessary if they could have performed the migration now. We can regard that extra work as the (metaphorical) interest charges on that technical debt.
The policymaker’s perspective
Some — indeed most — conventional views of technical debt do not regard the deferred upgrade as technical debt, for various reasons: it isn’t software, or it isn’t in a product, or it isn’t a shortcut taken for expedience, and so on. Moreover, the person who made the decision to take on the debt was the CFO, who is not an engineer, and who might not even realize that the implications of the decision result in taking on technical debt.
But from the viewpoint of the policy maker, the commitment to execute the upgrade in the future is equivalent to accepting a technical obligation. For the enterprise, it is a technical debt. Following UGI’s current account procedures, the metaphorical interest on that technical debt will be paid by the SharePoint users and by IT, and it will appear as an operating expense for those groups. That’s unfortunate, because the purpose of deferring the upgrade was unrelated to their operations. It was an enterprise cost-leveling maneuver whose costs should probably be accounted for at the enterprise level to ensure that operational costs for the SharePoint users and for IT are accurately represented, and to accurately represent the CFO’s operations.
Non-technical decisions, occurring anywhere in the enterprise, can sometimes lead to incurring technical debt. Enterprise policy intended to support effective technical debt management must take these phenomena into account.
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.
[Kruchten 2013] Philippe Kruchten, Robert L. Nord, Ipek Ozkaya, and D. Falessi, “Technical debt: towards a crisper definition report on the 4th international workshop on managing technical debt.” ACM SIGSOFT Software Engineering Notes, 38:5, 51-54, 2013.
Includes a comment that testing debt is not technical debt. Includes a comment that technical debt is result of quick and dirty work.
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 is not actually technical debt.
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.
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.
This post is for readers who are skeptical that technical debt is much of a problem, or who might be thinking that it’s just the latest buzzword the engineers have cooked up to justify bigger budgets or late deliveries.
Of course I have no knowledge of your specific situation, but technical debt is a real thing, it probably affects your organization, and skepticism, though usually healthy, is unwise when it comes to technical debt. Here’s the short version:
If you produce or use technology in your organization, you’re probably carrying technical debt, it’s costing you real money, it’s slowing you down, and unless you address it, it will increase, and eventually take you out of the game.
A knight’s armor. To this day, in the United Kingdom, a law entitled ‘Statute Forbidding Bearing of Armour (1313)’ remains in effect. As bodies of legislation grow and evolve, they develop inconsistencies, and outmoded laws accumulate. They are the legislative equivalent of technical debt.
Technical debt makes systems more difficult to maintain, less cybersecure, more difficult to enhance, more expensive to operate, and less effective in achieving organizational objectives. Although there is some disagreement about the definition of technical debt, there is broad agreement that the problem is growing rapidly [Fowler 2003]. If current trends continue, or accelerate, someday soon many of our technology-based assets will become unmaintainable and cyber-indefensible. The people, enterprises, and governments that depend on those assets will be unable to adapt rapidly enough to changing markets, changing technologies, changing cyber-threats, and changing customer needs. If we are ever to gain effective control of technical debt, we must change organizational technology management policy.
Technical debt afflicts organizations of all sizes. The really big problems — the ones that sometimes make the news — tend to belong to big corporations. For example, Google’s code base of “hundreds of millions” of lines of code once contained dependencies among its modules that were ungoverned (and ungovernable) [Morgenthaler 2012]. The sheer number of dependencies and the frequency of changes so slowed the development process that it affected Google’s operations. They dealt with this form of technical debt with three strategies: exploit automation, make it easy to do the right thing, and make it hard to do the wrong thing.
But small companies are also affected. Consider the fictitious company Alpha Properties LLC, which manages small condominium associations (fewer than 100 units). They provide excellent value to small clients by exploiting automation to keep their own operating expenses low. Many of their automation assets are implemented as Microsoft Excel macros. When Microsoft released Excel 2013, Alpha’s macros would have been affected, and they elected to incur technical debt by remaining in Excel 2010. However, mainstream support for Excel 2010 ended in October 2015, with extended support scheduled to end in October 2020. Alpha realizes that they must retire this debt well before that, but finding the resources to do it has been a challenge.
For non-engineers, and specifically for policymakers, what exactly is the technical debt problem? It’s a problem that afflicts complex technological assets, where a technological system is almost anything humans can construct, including highways, bridges, computers, satellites, software — anything. And that includes a class of assets that have no physical manifestation, such as software, surgical procedures, and legislation. All these assets have associated bodies of knowledge, both of which evolve. When they do evolve, technical debt can arise, and it can reside in the asset, in its associated body of knowledge, in the assets we use to interact with the asset, or all three.
We’re dealing with the consequences of the technical debt problem when we’re aware of structures within or around an existing asset that can be improved, but those improvements have been deferred. Subsequently, we find that making a change to an existing asset is so complicated and such a delicate matter that only a few experts can undertake the effort successfully. When they do, the cost of the effort is difficult to predict with useful precision, and there’s a significant probability of their failing multiple times before they finally succeed — if they ever do succeed. When we include all cost sources, costs can be high enough to rival or exceed the initial development cost of the asset, even when the changes in question seem relatively small.
Briefly, the technical debt problem is that as technological assets evolve, they can become increasingly difficult to maintain, defend, enhance, or extend. The difficulty can become so great that many owners of technological assets choose to begin anew rather than continue to operate the assets they have.
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.
[Kruchten 2013] Philippe Kruchten, Robert L. Nord, Ipek Ozkaya, and D. Falessi, “Technical debt: towards a crisper definition report on the 4th international workshop on managing technical debt.” ACM SIGSOFT Software Engineering Notes, 38:5, 51-54, 2013.
Includes a comment that testing debt is not technical debt. Includes a comment that technical debt is result of quick and dirty work.
[Morgenthaler 2012] J. David Morgenthaler, Misha Gridnev, Raluca Sauciuc, and Sanjay Bhansali. “Searching for Build Debt: Experiences Managing Technical Debt at Google,” Proceedings of the Third International Workshop on Managing Technical Debt (MTD 2012), Piscataway, NJ: IEEE Press, 2012, 1-6.