Category: Cases

Fictitious cases or examples of scenarios involving technical debt, in which we look at how the debt was incurred, what its effects were, or how it was retired. The cases we examine are designed to illustrate the importance of a whole-enterprise perspective of technical debt. They show how the different elements of the enterprise interact through technical debt and its consequences.

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.

Related posts

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.

Share this:

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

Kruchten 2013

Related posts

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.

Share this:

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

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

Kruchten 2013

Related posts

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.

Share this:

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]