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