The MPrin of new technical debt associated with a development project is usually taken to be the difference between the cost of implementing it in a sustainable manner and the cost of simply making it work. The effort saved by choosing the latter over the former is typically identified as the initial MPrin of the technical debt.
For example, in an enhancement project for an existing asset, after we finally achieve an operational capability, we might recognize that we have duplicated some functionality that already existed elsewhere in the asset. In such cases, the responsible, debt-free approach would be to first remove the duplication, then to modify the asset to use the previously existing approach, and finally to re-test the asset. By leaving the duplication in place, we save all that effort (and time), which many regard as the MPrin of a technical debt.
In a closely related example, we might recognize that the duplicated functionality in the newly developed portion of the asset is superior to the pre-existing form elsewhere in the asset. We’d like to remove the pre-existing form and replace instances of that form with instances of the newly developed functionality. But that work is clearly outside the scope of the new development, and it must await budgetary authority before it can be undertaken. Consequently, it becomes technical debt for the larger asset.
As time passes, and the enterprise undertakes other development projects, the implementations of previous projects can accumulate additional technical debt. The more obvious mechanisms by which this occurs include defect discovery, customer requests for enhancements, the need to enhance cyberdefenses in response to new threats, or changes in law or regulation.
An example of a less obvious process might be insights gained in marketing one product, which we shall call P1, that reveal an opportunity to introduce other related products, P2, P3, and P4, to form a suite. The latter products could employ some of the assets developed for or contained in P1, if they had been constructed slightly differently. The changes required in P1 therefore constitute technical debt, because we would have been able to develop P2, P3, and P4 much more rapidly if we had recognized the opportunity earlier. The P1 changes then become technical debt. And if we pursue P2, P3, or P4 without first retiring that debt, the debt probably expands, because it’s mirrored in the subsequent products.
New product (or service) developments often generate these situations.
Available: here Retrieved: November 21, 2017