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.
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; .
[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
