Contract restrictions can lead to technical debt

Last updated on July 8th, 2021 at 01:42 pm

When the owner of an asset, especially a software asset, contracts to provide a capability to a customer incorporating a use of that asset, contract restrictions can lead to technical debt. The work involved might require modification or enhancement of that asset. When the contract permits such work without transferring ownership of the asset itself, performing it is relatively straightforward. But complications can arise unless the contractor can perform the work in a manner compatible with any pre-existing or anticipated future other uses of the asset. Even so, some contract restrictions can cause the owner of the asset to incur technical debt.

How technical debt can enter the picture

Some contracts restrict such work. For example, a government customer might require ownership of the work performed. Potentially, all of the work might be classified as a national secret. In either of these cases, to retain control of the asset, the owner/contractor arranges to perform all of the work outside the periphery of the asset. To accomplish this, the owner/contractor might interface to the asset through an adaptor that the government customer can then own, or which can be classified as secret if necessary. These moves insulate the original asset from these ownership restrictions.

The result is tolerable after completion of one such contract. But over time, as their number increases, the adaptors become a form of technical debt. The asset owner must maintain each adaptor against any changes in the original asset. Moreover, making changes to the original asset can become a project of such scale that the temptation to create a static “clone” of the asset for each customer is irresistible. When that happens, cloning replicates both the asset and any technical debt it carries. And correcting defects in the asset requires correcting that same defect in any clones that carry it.

The general forms of the problem

The problem is more general than suggested above. It also appears in the case of software that supports multiple platforms, or which is available in multiple versions supporting a single platform.

But it gets worse. Suppose the maintainers decide to update the asset to make it more extensible, or to make it more maintainable. They must then perform that update, including all testing and documentation, on each clone. If the asset owner elects not to update all clones, then the clones will begin to diverge from each other. Engineers performing tasks on one of the clones must then have knowledge of how that clone differs from other clones. If they discover a new defect, it might or might not be present in every clone. Implementing a new extension or other modification might not be possible in all clones. Or implementing it in some clones might require a unique approach. Life can get very complicated.

Organizations entering into contracts of this kind would be wise to include language limiting their obligations to maintain the original asset against any changes. Or they might include an explicit statement of the parties’ intentions relative to financial support for any continuing obligations to maintain that asset.

Last words

Organizations offering products for multiple platforms would be wise to consider as strategic the management of technical debt that arises from platform multiplicity. Sound management of this form of technical debt can extend their ability to support multiple platforms. And that can dramatically increase returns on investment in the core asset.

Other posts in this thread

• Nontechnical precursors of nonstrategic technical debt
• Failure to communicate long-term business strategy
• Failure to communicate the technical debt concept
• Technological communication risk
• Team composition volatility
• The Dunning-Kruger effect can lead to technical debt
• Self-sustaining technical knowledge deficits during contract negotiations
• Performance management systems and technical debt
• Zero tolerance and work-to-rule create adversarial cultures
• Stovepiping can lead to technical debt
• Unrealistic definition of done
• Separating responsibility for maintenance and acquisition
• The fundamental attribution error
• Feature bias: unbalanced concern for capability vs. sustainability
• Unrealistic optimism: the planning fallacy and the n-person prisoner’s dilemma
• Confirmation bias and technical debt
• How outsourcing leads to increasing technical debt
• How budget depletion leads to technical debt
• Organizational psychopathy: career advancement by surfing the debt tsunami
• The Tragedy of the Commons is a distraction
• The Broken Windows theory of technical debt is broken
• Malfeasance can lead to new technical debt