Contract restrictions can lead to technical debt

Last updated on May 23rd, 2021 at 09:13 am

When the owner of an asset, especially a software asset, contracts to provide a capability to a customer incorporating a use of that asset, 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, provided the work can be done in a manner compatible with any pre-existing or anticipated future other uses of the asset. But some contract restrictions can cause the owner of the asset to incur technical debt.

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.
The wide variation in electric power standards worldwide can be viewed as a technical debt. Someday, in the probably distant future, a world standard will emerge and that debt will be retired. Until then, adaptors like these are travel necessities.

But some contracts restrict such work. For example, for a government customer, ownership of the work performed might be required to transfer to the government customer. 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 can be transferred to the government customer, or which can be classified as secret as the case may be, thereby insulating the original asset from these ownership restrictions.

The result is tolerable after one such contract is completed. But over time, as the number of adaptors increases, they become a form of technical debt. Each must be maintained 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, any technical debt already present in the asset is also cloned. And any work performed to correct defects in the asset must be performed on each affected clone.

The problem is more general than suggested above. It also appears in the case of software offered for multiple platforms, or multiple versions of 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. That update, including all testing and documentation, must then be performed 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 it differs from other clones. If a new defect is discovered, 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 it might have to be implemented differently in some clones. Life can get very complicated.

Organizations entering into contracts of this kind would be wise either to include language limiting their obligations to maintain the original asset against any changes, internal or external, in its ability to perform its functions. Or they might include an explicit statement of the parties’ intentions relative to financial support for any continuing obligations to maintain that asset.

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, which 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.