Tag: metaphorical interest charges

Posted on

Technical debt in the highway system

Last updated on July 18th, 2021 at 07:08 pm

The ghost ramps of highway I-695 in Somerville, Massachusetts
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.

Related posts

  • Case 3: Help desk operations
    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.
  • Case 2: New software Development
    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.
  • Case 1: A platform upgrade
    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.
  • Technical debt in a rail system
    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.
Posted on

Case 3: Help desk operations

Last updated on July 7th, 2021 at 10:32 am

This case illustrates how a decision to incur technical debt in one part of an organization can burden others with the metaphorical interest charges (MICs) on that debt. To gain effective control of technical debt, hold accountable those who make the decisions that lead to incurring new debt.

Background

A tech support person at workDuring 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. Customer Service alerted Engineering. Engineering provided an explanation and an estimated repair date to pass on to callers. But neither Engineering management nor Customer Service management provided a script for the representatives. Consequently, calls took approximately 15% longer to handle than they would have if with a script. Further, the message conveyed to customers wasn’t always clear or consistent. That resulted in some customers calling repeatedly with the same issue.

Discussion

We can view as incurring a technical debt the decision not to provide customer service representatives with a script. We can view as the metaphorical interest charges the extra time handling calls, the extra calls, and even a few lost customers. Because of the singular nature of this incident, it’s doubtful that anyone will write a script. But if someone were to do so, the cost of writing it, 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 holding accountable those who incurred the debt. In this case, the Customer Service function incurs additional expenses because Engineering and Customer Service elected not to develop a script.

Other components of the metaphorical interest charges include 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 didn’t participate. A whole-enterprise perspective on managing the technical debt might have led to a collaboration among Engineering, Marketing, and Customer Service. That collaboration could help build better relationships with the customers who were affected by the incident.

Accounting properly for the MICs associated with technical debt can lead to a better understanding of its effects.

Related posts

  • Case 2: New software Development
    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.
  • Case 1: A platform upgrade
    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.
  • Technical debt in the highway system
    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.
  • Technical debt in a rail system
    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.
Posted on

Case 2: New software Development

Last updated on July 7th, 2021 at 10:30 am

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.

Background

A typical smartphoneGrowth has been unbelievable at Unbelievable Growth, Inc., (UGI). One reason why is the recent release of their app for Android and iPhone. The new app is StrawIntoGold 1.0. The app has an uncanny ability to predict the price movement of any common stock 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. So UGI hired 17 interns just for that release. The interns performed some critical tests manually to ensure that the problem had been fixed. Although those manual tests are still manual, and although UGI has laid off the interns, work on StrawIntoGold 2.0 has begun. 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 tests as incurring a technical debt. That debt consists of the tests that weren’t automated. Until UGI retires that debt, it will incur something analogous to interest charges, as reduced engineering productivity. They raise production costs for the next release. They also delay the revenue projected for StrawIntoGold 2.0. That causes a loss of revenue, which is another contribution to metaphorical interest charges. The metaphorical principal of the technical debt imcludes the cost of implementing the automated tests. It also includes documentation and training for the engineers who will be using them.

The policymaker’s perspective

Some conventional views of technical debt don’t 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, 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.

Allocating resources to technical debt management is difficult for organizations unless they know the full costs associated with carrying technical debt.

References

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

Cited in:

Related posts

  • Case 3: Help desk operations
    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.
  • Case 1: A platform upgrade
    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.
  • Technical debt in the highway system
    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.
  • Technical debt in a rail system
    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.
Posted on

Case 1: A platform upgrade

Last updated on July 18th, 2021 at 07:13 pm

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
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. Resources are especially tight 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 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 migrate that work to the SharePoint 2013 site. Unfortunately, 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 isn’t 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 policymaker, the commitment to execute the upgrade in the future is equivalent to accepting a technical obligation. For the enterprise, it’s a technical debt. Following UGI’s current accounting procedures, the SharePoint users and IT will pay the metaphorical interest on that technical debt. 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. As such, the enterprise should probably account for the costs at the enterprise level to ensure accurate representation of the operational costs for the SharePoint users and for IT, 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] 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.

Cited in:

Related posts

  • Case 3: Help desk operations
    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.
  • Case 2: New software Development
    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.
  • Technical debt in the highway system
    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.
  • Technical debt in a rail system
    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.
Show Buttons
Hide Buttons