Last updated on November 24th, 2017 at 06:59 pm
This post is for readers who are skeptical that technical debt is much of a problem, or who might be thinking that it’s just the latest buzzword the engineers have cooked up to justify bigger budgets or late deliveries.
Of course I have no knowledge of your specific situation, but technical debt is a real thing, it probably affects your organization, and 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, and eventually take you out of the game.
Technical debt makes systems more difficult to maintain, less cybersecure, more difficult to enhance, more expensive to operate, and less effective in achieving organizational objectives. Although there is some disagreement about the definition of technical debt, there is 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 organizations of all sizes. The really big 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, which manages small condominium associations (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, and 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.
For non-engineers, and specifically for policymakers, what exactly is the technical debt problem? It’s a problem that afflicts complex technological assets, where a technological system is almost anything humans can construct, including highways, bridges, computers, satellites, software — anything. And that includes a class of 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, and 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 the technical debt problem when we’re aware of structures within or around an existing asset that can be improved, but those improvements have been deferred. Subsequently, we find that making a change to an existing asset is so complicated and such a delicate matter that only a few experts can undertake the effort successfully. 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.
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
