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