How technical debt can create more technical debt

Last updated on November 28th, 2017 at 11:29 am

Decisions to defer technical debt retirement must take into account phenomena that, if left unattended, can lead to (a) increasing volume of a given , (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.

References

[Martini 2015] A. Martini and J. Bosch. “The danger of architectural technical debt: Contagious debt and vicious circles,” Working IEEE/IFIP Conf. Softw. Arch., 2015.

• Debt contagion: how technical debt can create more technical debt

[Pugh 2010] Ken Pugh. “The Risks of Acceptance Test Debt,” Cutter Business Technology Journal, October 2010, 25-29.

• A policymaker’s definition of technical debt
• Debt contagion: how technical debt can create more technical debt

Related posts

• MPrin for missing or incompletely implemented capability
  In some instances, technical debt is actually a missing or incompletely implemented capability. If we retire the debt by completing the implementation, the MPrin is the cost of that effort, plus any training, testing, and lost revenue. If we retire the debt by halting or withdrawing the capability, the MPrin is the total cost of removal, plus testing and lost revenue.
• MPrin when standards or regulations change
  The Metaphorical Principal of a technical debt that’s incurred as a result of a change in standards or regulations, internal or external, is the cost of bringing all affected assets into full compliance. Properly accounted for, however, the MPrin should include ripple effects, which are the changes in other assets that are required to keep them compatible with the assets that are directly affected.
• MPrin in platform component upgrades
  Platform component upgrades often trigger the need to make changes in whatever sits atop the platform, to maintain compatibility with the platform. Those changes obviously contribute to MPrin. But less obvious are the contributions that arise from deferring the upgrade.
• MPrin in a development project
  The MPrin of an asset that is subjected to new development or enhancement has some special characteristics. For an existing asset, new development can lead to duplication of capability. For new assets, unanticipated opportunities can transform into technical debt components that were not viewed as technical debt, without ever changing them in any way.
• Examples of MPrin in four scenarios
  Some examples might help to clarify the differences between the principal of financial debts and the Metaphorical Principal of a technical debt. The examples to come in the next four posts are designed to illustrate the unique properties of MPrins of technical debts.
• The metaphorical principal of a technical debt
  The principal amount of a financial debt and the metaphorical principal of a technical debt have very different properties. They are so different that it’s wise to avoid using the term “principal” to refer to the metaphorical principal of a technical debt. We use the term MPrin.