Case 3: Help desk operations

Last updated on November 21st, 2017 at 08:34 am

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

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

Case 2: New software Development

Last updated on November 21st, 2017 at 08:35 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 is not actually technical debt.

Background

A typical smartphoneOne 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] 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 1: A platform upgrade

Last updated on November 21st, 2017 at 08:35 am

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

Show Buttons
Hide Buttons