MPrin in a development project

Last updated on July 7th, 2021 at 11:12 am

The "basket bridge" of the Los Angeles Metro system
The “basket bridge” of the Los Angeles Metro system. Constructed by the Metro Gold Line Foothill Extension Construction Authority, and opened in 2012, it carries the Los Angeles to Pasadena Metro Gold Line light rail across the eastbound lanes of the I-210 Freeway. The rail line provides transport service to a ridership that had been driving or using bus service. Although the bus and rail aren’t exact duplicates of each other, there is enough overlap that bus ridership dropped significantly after the rail line opened. That drop created a technical debt in the bus system. Retiring that debt requires reducing, rescheduling and re-routing bus service [Broverman 2017].

We usually regard the MPrin of new technical debt associated with a development project as the difference between the cost of implementing it sustainably and the cost of simply making it work. The effort saved by choosing the latter over the former is the initial MPrin of the technical debt.

For example, consider an enhancement project for an existing asset. After we achieve an operational capability, we might notice that we’ve duplicated some of the asset’s pre-existing functionality. The responsible debt-free approach has three stages. First, we eliminate the new and unnecessary duplicated capability. Next, we modify the asset to use the previously existing capability. Finally, we re-test the asset. The approach that generates new debt involves leaving the duplication in place.

Other generators of 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. Less obvious, but no less significant, are changes in markets, customer needs, and underlying technologies. All can contribute to technical debt formation

A final example

An example of a less obvious process might be insights gained in marketing one product (call it P1). Suppose those insights reveal an opportunity to introduce other related products—P2, P3, and P4—to form a suite. The latter products could employ some assets developed for P1, if the latter products 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 the subsequent products manifest it.

New product (or service) developments often generate these situations.


[Broverman 2017] Neal Broverman. “The Success of the Gold and Expo Lines Has Taken a Toll on Bus Ridership,” Los Angeles Magazine, March 30, 2017.

Available: here; Retrieved: November 21, 2017

Cited in:

Related posts

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