Bankrolling Technical Debt: A Financier�s Guide
As a new contributor, we've been looking more closely at the conversations that go on at Wall Street & Technology, and we noticed there isn't much written on technical debt -- which honestly surprised us. It's a very important topic in technology, and it should resonate well in finance circles, because technologists borrowed this term from there in the first place.
Since we're talking about debt, and this is a finance crowd, we thought we'd help decipher some of the confects of technical debt in your own terms. But before we make any comparisons, let's define what technical debt actually is.
What is technical debt? Technical debt represents the effort required to fix problems that remain in the source code of an application after it is released. It also represents the cost of fixing structural quality problems in an application that put the business at serious risk. This includes only those problems that are highly likely to cause severe business disruption. It does not include all problems -- just the most serious ones.
Where does it come from? Just as a business might incur some debt in order to take advantage of a market opportunity, developers may incur technical debt to hit an important deadline. Sometimes the debt is inadvertent due to lack of skills or poor architecture control. Since this debt is off the balance sheet, it's quite common for technology-driven organizations to let their debt get out of control and spend most of their IT effort trying to survive the crippling interest payments.
How does it affect an organization? Technical debt interest payments come in the form of extra effort during future development or volatile, incident-prone systems in production. Though it costs to pay down or prevent the principal, we gain by reducing the interest payments in the future. This leads us to the basic definitions that technologists have for technical debt today.
Principal: This is the cost of refactoring the codebase to a clean design, which would make future changes easier. In a perfect world, organizations would simply make these changes and endow themselves with highly robust applications, but many choose solely to pay the interest.
Interest: This is the increased maintenance cost and lower IT responsiveness that result from outstanding technical debt. This would include the cost of taking longer to implement a new feature (real and opportunity costs), the cost of fixing minor bugs and making updates, and the cost of recovering from a catastrophic system crash.
Now that we have the basic definitions for technical debt, let's look at some of the financial constructs we could envision if technical debt were actually tracked on the balance sheet.
Technical debt bonds: An organization that has taken on significant technical debt could issue bonds in order to sell some of that debt in exchange for interest payments to the buyer. The bond issuer would use the proceeds from the sale to repair its technical debt, reaping huge rewards in terms of time to market and reduced software risk. The issuer would pay some of those gains to the bond buyer in the form of interest, accumulating the savings to pay back the principal. Those organizations that know they have a lot of technical debt would be able to offer the most attractive yields.
Technical debt yield curve: This should follow the typical yield curve in the industry, since the long-term payback for technical debt reduction tends to be higher than the short-term payback. However, if the technical debt yield curve were inverted, there would be many borrowers desperate to pay down some debt right away. That would signal to the markets that our trading systems will soon be a lot less table, which will probably have the same effect as a conflict in yet another oil-producing region.
Technical debt call option: Some organizations might decide that they are comfortable locking themselves into a fixed-term, fixed-interest agreement to pay down their technical debt. Others might figure they should retain the option to pay back their debt before maturity. Debt with a call option would naturally be a few dozen basis points more expensive.
Technical debt risk rating: Like any loan or liability, each piece of technical debt comes with a certain risk factor. Some technical debt is more risky than others. For example, are we dealing with a very complicated piece of code that might slow the system down, or is it a serious security flaw that could expose the business? Both could cost an organization millions to fix, but if you're buying an outsourced application, you'd certainly like to see how risky that technical debt is up front. If any of these risks manifested, they could cause the team to default on technical debt obligations.
Technical debt junk bonds: Some organizations will have very little credibility when committing to technical debt reversal in order to reap the interest payment gains. Ratings agencies might label such bonds as high risk, driving down the prices and thereby increasing the returns. Organizations whose technical debt been labeled as junk will find it expensive to borrow more, and they may have to scrap all their applications to start over.
Technical bankruptcy protection: When an organization realizes that it has no way to repay its debts, and its technical debt risk rating cannot escape junk status, the management can decide to seek bankruptcy protection. This is a state where the applications are in such disrepair it would take much longer to fix all of them than it would be to rewrite them from scratch. Bankruptcy can provide the means to build new systems, using the knowledge gained from past experience to ensure the new systems do not fall into such a state of disrepair.
We know this article is a little tongue in cheek, and it takes some liberties with the metaphors, but this should help our finance colleagues get their head around technical debt. In reality, many technologists in finance do understand the concept, but they struggle to communicate the risk they are taking on by indulging in technical debt. Maybe some of these concepts can help. In later posts, we'll dive deeper into pragmatic approaches for finance technology organizations to measure, monitor, manage, and reverse their technical debt.
Lev Lesokhin is executive vice president of strategy for CAST. He is responsible for market development, strategy, thought leadership and product marketing worldwide. He has a passion for making customers successful, building the ecosystem, and advancing the state of the art ... View Full Bio
Tweet This