|Summary||Although the MPrin of a given class of technical debt can increase or decrease even if instances of that debt remain untouched, the total volume of all other technical debt can change as well. If a class of technical debt is allowed to remain outstanding, its volume can increase as a consequence of seemingly unrelated actions or decisions. Moreover, its existence can cause increases in the volume of other existing classes of technical debt, and its existence can lead to the formation of new classes of technical debt. When formulating technical debt management policy, it's essential to understand these mechanisms and risks
Decisions to defer technical debt retirement must take into account phenomena that, if left unattended, can lead to (a) increasing volume of a given class of technical debt, (b) increasing volume of other existing classes of technical debt, and (c) generating new classes of technical debt. An example can illustrate this behavior.
Suppose we have a fleet of desktop computers, running a mix of operating systems. A few of these systems are running Windows 8 and the rest are running Windows 10. We’d like to upgrade the Windows 8 machines to Windows 10, but we cannot, because some of their users need access to a (fictional) scriptable application called CRUSH that is not available for Windows 10. CRUSH for Windows 10 is promised “shortly.” Instead of asking our CRUSH users to find an alternative to CRUSH, we defer the Windows 8 upgrade, in the hope that CRUSH for Windows 10 will soon arrive. Meanwhile, other Windows 8 users are happy to continue using Windows 8, and some of them have acquired — and have grown fond of using — another similar (fictional) scriptable package called REMOTE, which is also unavailable for Windows 10. Worse, the CRUSH user community is continuing to grow. Thus, by deferring the Windows 8 upgrade, we have made space for additional problems preventing the upgrade to Windows 10. The technical debt associated with the Windows 8 upgrade now includes Windows 8 itself, and all the scripts, documents, and knowledge that are accumulating for both CRUSH and REMOTE.
The lesson here is not to ban scriptable applications, nor to compel desktop users to adhere to an enterprise standard. Both options create numerous problems. The point of the example is merely that deferring debt retirement can enable formation of new instances of existing technical debt (the growth of the CRUSH user community and the assets they continue to develop) and new, unrelated debt (the introduction of REMOTE). Thus, if we make a decision to defer retirement of a class of technical debt, we must consider all costs of such deferment, including expansion of the total volume of technical debt, and all its consequences, as expressed as metaphorical interest charges and MPrin.
Some of the new technical debt that forms when we leave existing debt in place is closely related to the existing debt. For example, once we’ve implemented some part of an asset in a way that we now acknowledge contains a form of technical debt, we tend to apply that same approach when we undertake extensions or enhancements, rather than using what everyone might acknowledge is a superior approach. Martini and Bosch have identified a phenomenon they call debt contagion [Martini 2015], whereby creating new system elements in forms compatible with elements already identified as debt effectively causes debt propagation. This practice helps us maintain some degree of uniformity in the asset, recognizing that in doing so we’re increasing the MPrin of a given class of technical debt. These future expansions of MPrin can be difficult to predict at the time we first incur the debt, or at any time.
However, some forms of technical debt are far less discriminating with respect to the kinds of technical debt they spawn. Debt with this property tends to be associated with the processes used to develop or maintain technical assets. In “A policymaker’s definition of technical debt,” we cite Pugh’s example of acceptance test debt as a form of technical debt [Pugh 2010].
But acceptance test debt can reduce the ability of the organization to retire technical debt. In the absence of automated acceptance tests, testing system components from which technical debt has recently been removed is less efficient and reliable than it would be if automated acceptance tests were available, which retards debt retirement activity and which might even prevent the organization from attempting debt retirement in some circumstances. In a future post, we shall describe how a deficient regime of reviews and inspections can also lead to incurring new technical debt, or to elevated levels of legacy technical debt.
Our final example illustrates how interfaces — which, ironically, were conceived to insulate one portion of an asset from others — can act so as to propagate technical debt. This example could apply to either hardware or software. Given a system S composed of several modules, suppose that module M of S provides services of some kind to several other modules of S. M does contain some technical debt, of a form whose retirement would simplify M’s interface. Because that change would require changes to the modules that use M’s services, retiring the debt has been deferred. Meanwhile, new modules are being introduced into S, and, of course, they must use M’s existing interface. The MPrin of the technical debt associated with M’s interface thus expands.
Unless we provide an alternate version of M (call it M’) or an alternate interface to M, this process of MPrin expansion can repeat whenever new modules are introduced into S. But even if we do provide M’ or an alternate interface to M, engineers must consciously refrain from using the older approaches. Some will refrain, but some might not. Those who are under severe schedule pressure, or those who cannot or will not learn the new approaches, or those who are directed not to use the new approaches, might continue to use the familiar approaches as long as they are able. The MPrin associated with M can thus continue to expand, albeit perhaps at a reduced rate.
Technical debt, left in place, can grow and spawn new forms of technical debt. Make technical debt retirement a priority.
[Martini 2015] Martini, A. and Bosch, J. “The danger of architectural technical debt: Contagious debt and vicious circles,” Working IEEE/IFIP Conf. Softw. Arch., 2015.
[Pugh 2010] Ken Pugh. “The Risks of Acceptance Test Debt,” Cutter Business Technology Journal, October 2010, 25-29.