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

A power adaptor/converter for international travelers with U.S. standard equipment.
A power adaptor/converter for international travelers with U.S. standard equipment. This device provides conversion for both hardware connection and voltage supplied.
We can regard the wide variation in electric power standards worldwide as a technical debt. Someday, in the probably distant future, a world standard will emerge and we will retire that debt. Until then, adaptors like these are travel necessities.
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

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Show Buttons
Hide Buttons