Last updated on July 8th, 2021 at 12:44 pm
Few senior management teams would seriously consider making decisions about financial instruments without carefully estimating their effects on revenue and expenses. Most enterprises support decision makers with an impressive array of tools, historical data, and skilled financial professionals. Yet few organizations invest at similar levels to support estimators of the MICs involved in undertaking engineering efforts. A similar dearth of resources affects those who estimate the effects on revenue due to carrying technical debt.
A resource shortage of this kind can have starkly negative effects. The inherent difficulties of projecting the effects of both carrying and retiring technical debt create uncertainties in project budgets and schedules.MICs can fluctuate dramatically depending on a range of factors. These factors include:
- The kind of work underway on the asset that carries the debt
- How the debt affects customers and what they’re doing at any given time
- The difficulty of researching engineering problems arising from the debt
- The loss of revenue due to debt-related delays in reaching the market
- A loss of sales due to semi-catastrophic failures in customer demonstrations
In short, MICs are often unpredictable [Allman 2012].
The state of the art
Most of the research into the effects of carrying or retiring technical debt has focused on engineering activity, and specifically, software engineering activity [MacCormack 2016] [Kamei 2016]. By comparison, research has been less intensive for effects on other activities—marketing, sales, regulatory compliance, to name a few. And in many cases, the effects of technical debt on these other activities are the most significant.
Consider first the effect of technical debt on enterprise expenses. The kind of maintenance and enhancement work performed on a set of assets bearing technical debt can determine the depressive effect on productivity. And declines in productivity directly affect MICs. In many cases, projecting future MICs associated with any given class of technical debt can be difficult. The difficulty arises because we might not know with sufficient certainty what projects will be active in the intermediate term or long term future, and what kind of work those projects will undertake. Even when we do know these things, the level of involvement with instances of particular classes of technical debt can be difficult to project enough certainty to be useful.
Turning to revenue, for most organizations, the picture is also bleak. Because we can’t retire some classes of technical debt incrementally, retirement projects can have significant impact on operations and revenue. Research in this area is even more limited than in the area of effects on productivity.
Last words
Projecting MICs with useful accuracy would be a valuable capability. Making MICs more predictable would require systematically gathering data and building expertise for projecting MICs for your enterprise. That problem is more tractable than the more general problem of projecting MICs absent specific knowledge of enterprise characteristics.
An enterprise-specific MICs projection capability could elevate the quality of decisions regarding resource allocation for projects of all kinds, including technical debt retirement projects. Policymakers can play an important advocacy role in establishing such a capability.
References
[Allman 2012] Eric Allman. “Managing Technical Debt: Shortcuts that save money and time today can cost you down the road,” ACM Queue, 10:3, March 23, 2012.
Available: here; Retrieved: March 16, 2017
[Kamei 2016] Yasutaka Kamei, Everton Maldonado, Emad Shihab, and Naoyasu Ubayashi. “Using Analytics to Quantify the Interest of Self-Admitted Technical Debt,” 1st International Workshop on Technical Debt Analytics (TDA 2016), 68-71.
Available: here; Retrieved: November 28, 2017
[MacCormack 2016] Alan MacCormack and Daniel J. Sturtevant. “Technical debt and system architecture: The impact of coupling on defect-related activity,” The Journal of Systems and Software 120, 170–182, 2016.
Available: here; Retrieved: November 19, 2017.