How MPrin can change spontaneously

Last updated on July 7th, 2021 at 10:53 am

Recall that our definition of the metaphorical principal of a technical debt (MPrin) at a given time is the cost of retiring the debt at that time. This cost can change with time. For example, due to ongoing maintenance and enhancements, the part of the asset in which the debt is embedded might become rather more complicated or constrained than it was earlier. That increased complexity can increase MPrin. This can happen even if the elements that comprise the debt itself have remained unchanged.

Moreover, the MPrin of any extensions to the asset in question, or to other assets, might also change. Those assets that use services provided by a subsystem manifesting the debt might also require alteration at debt retirement time. Untangling the debt from its surroundings, making necessary modifications, and testing the result, can be a delicate and complex process. The process might actually cost more at debt retirement time than whatever was saved when the debt was incurred.

An example of MPrin changing spontaneously

On the other hand, in some circumstances, the cost of retiring the debt can decrease over time. Consider the following fictitious example.

A high pressure sodium streetlight at dusk
A high pressure sodium streetlight at dusk. Photo (cc) Famartin courtesy Wikimedia Commons.

Zion is a small city of 110,000 that’s struggling with two problems related to street lighting. Its current streetlights use High-Pressure Sodium (HPS) lights. HPS lights use almost twice as much energy as do the newer LED streetlights for the same level of illumination. Zion’s second problem is that the existing streetlights provide only one level of illumination throughout the city. This is causing a stream of complaints from many residents who have concerns about street lighting spilling onto their property at night. The bright light interferes with the sleep patterns of people and their pets.

Both of these problems have technical solutions that became available after the current HPS lights were installed. That’s why we can view them as arising from technical debt. Zion had investigated resolving the light pollution problem, but couldn’t find an affordable solution. Time passed. When LED streetlights became widely available, Zion investigated retiring its HPS lights. They found an LED lighting system that was dimmable on a block-by-block basis using a wireless control system. By retiring the technical debt associated with the HPS lights, Zion was able to afford retiring the technical debt associated with its un-dimmable lighting system.

Zion was able to afford to retire both forms of technical debt at once because of the way they interacted, even though retiring them one at a time would have been too expensive.

This example shows that the MPrin of a technical debt can vary widely, depending on the assets involved, and on what other debts they carry. Such variation is far more common in the realm of technical debt than it is in the world of financial debt.

Related posts

Technical Debt: So What?

Last updated on July 8th, 2021 at 11:44 am

This post is for readers skeptical that technical debt is much of a problem. Some believe that technical debt is just the latest buzzword engineers use to justify budget and schedule overruns.

I have no knowledge of your specific situation, but technical debt is a real thing, and it probably affects your organization. Skepticism, though usually healthy, is unwise when it comes to technical debt. Here’s the short version:

If you produce or use technology in your organization, you’re probably carrying technical debt. It’s costing you real money, it’s slowing you down, and unless you address it, it will increase. Eventually it will take you out of the game.

A knight’s armor
A knight’s armor. To this day, in the United Kingdom, a law entitled ‘Statute Forbidding Bearing of Armour (1313)’ remains in effect. As bodies of legislation grow and evolve, they develop inconsistencies, and outmoded laws accumulate. They are the legislative equivalent of technical debt.
Technical debt makes systems more difficult to maintain, less cybersecure, more difficult to enhance, and more expensive to operate. This makes systems less effective in achieving organizational objectives. There is some disagreement about the definition of technical debt. But there’s broad agreement that the problem is growing rapidly [Fowler 2003]. If current trends continue or accelerate, someday soon many of our technology-based assets will become unmaintainable and cyber-indefensible. The people, enterprises, and governments that depend on those assets will be unable to adapt rapidly enough to changing markets, changing technologies, changing cyber-threats, and changing customer needs. If we are ever to gain effective control of technical debt, we must change organizational technology management policy.

Technical debt afflicts companies large and small

Technical debt afflicts organizations of all sizes. The massive problems—the ones that sometimes make the news—tend to belong to big corporations. For example, Google’s code base of “hundreds of millions” of lines of code once contained dependencies among its modules that were ungoverned (and ungovernable) [Morgenthaler 2012]. The sheer number of dependencies and the frequency of changes so slowed the development process that it affected Google’s operations. They dealt with this form of technical debt with three strategies: exploit automation, make it easy to do the right thing, and make it hard to do the wrong thing.

But small companies are also affected. Consider the fictitious company Alpha Properties LLC. Alpha manages condominium associations with fewer than 100 units. They provide excellent value to small clients by exploiting automation to keep their own operating expenses low. Many of their automation assets are implemented as Microsoft Excel macros. When Microsoft released Excel 2013, Alpha’s macros would have been affected. So they elected to incur technical debt by remaining in Excel 2010. However, mainstream support for Excel 2010 ended in October 2015, with extended support scheduled to end in October 2020. Alpha realizes that they must retire this debt well before that, but finding the resources to do it has been a challenge.

Technical debt exacts a high price

For non-engineers, especially policymakers, what exactly is the technical debt problem? It afflicts complex technological assets. That means almost anything humans can construct—highways, bridges, computers, satellites, software—anything. And that includes assets that have no physical manifestation, such as software, surgical procedures, and legislation. All these assets have associated bodies of knowledge, both of which evolve. When they do evolve, technical debt can arise. It can reside in the asset, in its associated body of knowledge, in the assets we use to interact with the asset, or all three.

We’re dealing with the consequences of technical debt when we’re aware of structures within or around an existing asset that can be improved, but we’ve deferred those improvements. Later, we find that making a change to an existing asset is so complicated and delicate that only a few experts can make the change. When they do, the cost of the effort is difficult to predict with useful precision, and there’s a significant probability of their failing multiple times before they finally succeed—if they ever do succeed. When we include all cost sources, costs can be high enough to rival or exceed the initial development cost of the asset, even when the changes in question seem relatively small.

Last words

Briefly, the technical debt problem is that as technological assets evolve, they can become increasingly difficult to maintain, defend, enhance, or extend. The difficulty can become so great that many owners of technological assets choose to begin anew rather than continue to operate the assets they have.

References

[Fowler 2003] Martin Fowler. “TechnicalDebt,” blog entry at MartinFowler.com, 1 October 2003.

Retrieved January 2, 2016, available at here; .

Cited in:

[Morgenthaler 2012] J. David Morgenthaler, Misha Gridnev, Raluca Sauciuc, and Sanjay Bhansali. “Searching for Build Debt: Experiences Managing Technical Debt at Google,” Proceedings of the Third International Workshop on Managing Technical Debt (MTD 2012), Piscataway, NJ: IEEE Press, 2012, 1-6.

Available: here; Retrieved: November 11, 2017

Cited in: