In some instances, technical debt is actually a missing or incompletely implemented capability. For example, absence of a fully automated regression test suite can create difficulties for testing a complex system after a series of modifications. Defects can slip through. That would result in reduced productivity and velocity. In this case, the projected cost of implementing, testing, and documenting the test suite, and training its users, would constitute the initial MPrin of the outstanding technical debt. This definition differs from some definitions, because it includes testing, documenting, and initial training. In general, from the enterprise perspective, when identifying the MPrin associated with missing or incompletely implemented capabilities, we must include all artifacts necessary to eliminate reductions in productivity and velocity.
But even if we include these items in the conventional definition, MPrin at retirement can exceed the savings at the time we incurred the debt. For example, the assets involved can change. Moreover, if retiring the debt a revenue stream interruption, and that revenue stream grows significantly, the MPrin, which includes the lost revenue, can also grow significantly.
Technical debt associated with incompletely implemented capability presents unique problems, because debt of this kind can be retired in three distinct ways. First, we can complete the implementation. The MPrin associated with this approach can grow beyond the initial cost of completion, for the usual reasons. Second, we can cancel the capability altogether. If that happens, retiring the debt completely would require removal of all artifacts that comprise the completed parts of the incomplete implementation. But full retirement can also require that we survey all components that interact with the retiring elements to determine whether they contain accommodations that are no longer necessary. Finally, we can choose a middle path, in which we adopt some parts that have been completed, reject other parts, and add whatever is necessary to create a limited version of what was originally planned.
It’s worth mentioning an important attribute of non-physical assets—software, procedures, legislation, regulations, and so on—that makes the technical debt associated with incomplete implementation so difficult to manage. The image above shows several levels of a concrete building under construction. The vertical members between the levels are part of a shoring system that supports the levels of the building until the concrete is cured well enough to support itself. They constitute a kind of technical debt that must be “retired” before the building can be completed. The teams constructing the building could never forget to remove the shoring because it gets in the way of installing the windows and walls.
But things are very different with non-physical assets. It’s easy to forget to remove intermediate artifacts, or elements that were being tried but didn’t work out. Many non-physical assets are perfectly functional carrying that kind of technical debt. The problems associated with that debt become evident with time, as the asset becomes increasingly difficult to maintain, extend, or defend.
It is this property of non-physical assets that makes technical debt management so much more difficult than it is with physical assets. Not more important, just more difficult.