On derivatives of technical debt: defining terms and players
In May 2019, I gave a talk at GlueCon, “Can We Trade Derivatives of Technical Debt?” The purpose of the talk wasn’t to answer the question literally. It was a way to rethink the tech debt analogy, where it’s gotten stuck, and where we can re-frame the analogy to have a useful conversation between technical teams and business stakeholders. I’ve published about understanding the risk profile of your technical debt separately. Here, I’ll define the terms of players needed to explore the derivatives side of the analogy.
Before we can extend the “tech debt” analogy to derivatives trading, we need to establish a few things. First, we need to define derivatives.
Derivatives: A layperson’s definition
I won’t provide an academic definition here. There are plenty of places on the Internet to get more detailed definitions. In layperson terms, however, most derivatives are an agreement. Derivatives are usually an agreement between two parties, usually for:
- Something to happen (e.g. option to buy or sell something)
- In some quantity (e.g. 500 shares in a company)
- In the event of something (e.g. the stock is “in the money,” a.k.a. it’s above/blow the strike price)
- Within a certain period of time (e.g. before the options contract expires)
If this sounds like a home owners insurance policy, you’re not far off. The house itself is the underlying asset. It’s insured for a certain amount and for a certain period of time. Certain types of events are covered by the policy. As we go on, we’ll see how other derivatives are kind of like insurance for other types of assets. That will be useful as we carry this analogy over to technical debt.
If you are familiar with stock options, you’ll recognize these four qualities to a derivatives agreement. These same aspects of the agreement apply to things like futures and interest rate swaps. Derivatives that trade on an exchange are standardized and regulated. But most derivatives are not exchange-traded. They are basically contracts between two parties.
Why do people (or organizations) buy and sell derivatives? At their core, derivatives are used to hedge, or offset, risk. One entity stands to gain with prices, interest rates, exchange rates, whatever going up. So, they use a derivative to gain something (and offset losses) if that thing goes down, for example.
If you own a stock, you already stand to gain if the price increases. You can buy an option to sell at a certain price, even if the price drops below that point. Effectively, you pay a little extra to lock in potential losses. Or a farmer that stands to gain if the price for their crop goes up and they use a futures contract to lock in a price for their crop. Or a business that stands to gain if the dollar gets weaker, so they write a contract to gain if the dollar gets stronger. These are all means of offsetting risk of potential losses. Of course, someone has to take the other side of that trade… the counterparty.
There’s another kind of derivative, which is also used to offset risk, which involve pooling assets. This is where mortgage-backed securities come in. Here, loans are pooled and then resold in tranches. Each tranche is like a slice of the full pizza pie that is the pool of mortgages. It’s still a way for the bank who lent the money to home buyers to offset the risk of defaults. In fact, the tranches can have different risk profiles, depending on the underlying buyer creditworthiness or home appraisal. This is where the notion of “prime” and “subprime” comes in.
The notion of classifying debt by different risk profiles is very useful when thinking about technical debt. Read my other post to understand the risk profile and interest rate on technical debt.
Who is the borrower? And who is the lender?
Thinking through the lens of derivatives brings certain parts of the tech debt analogy into sharp relief. It heightens the awareness of assessing risk profiles and interest rates since, after all, derivatives are about hedging risk. But derivatives are also a contract between two parties, and, at first glance, it’s unclear who those parties would be? Who is the borrower in this scenario, and who is the lender? We need this answered to know who is the party who would trade derivatives to offset their risk as a lender.
Most of the discussion around tech debt seems to revolve around the borrower’s experience. Borrowers have to make the interest payments, and get squeezed with a higher bill when rates spike. Technical teams express the pain of this burden with tech debt. After all, they are shouldering the work of changing the code. They also are the ones to “pay down” the debt in the form of retiring code. Does that make developers the “borrower” in this relationship? Maybe. But they also are more directly in control of the factors that set the interest rate.
Meanwhile, product owners, representing the business goals, also pay a price when interest rates spike and releases are delayed. The decision to rush a product out, even if it means taking on hard-to-change code, is usually a business-oriented decision. They want what the debt — the code — can buy: an application that drives business. Does that make product owners the borrower in this relationship? And would that make developers the lender?
I raised this question of “who is the lender in the tech debt analogy?” in my GlueCon talk, but my opinion has taken shape since. Technical teams are more directly in control of adjusting the interest rate. Despite how it may sometimes appear, technical teams are akin to the lender in these relationships, with the business as the borrower. Technical teams are underwriting loans to the business, which the business hopes are covered by growth or efficiency (i.e., cost savings). Healthy debt powers a growing economy, but lenders get nervous if they see unhealthy debt. Similarly, businesses face a number of risks when they take on too much code that is too hard to change.
***
We’ve established the basics of what derivatives are and who the lender and borrower are in the tech debt analogy. However, several questions remain to extend the tech debt analogy to derivatives trading. First, we’d need to understand who the counterparty would be to technical teams (the lenders). Who is taking the other side of that deal? Next, what is the event technical teams would want to insure against. What kind of agreement would protect against that event?
The questions don’t stop there and at a certain point we have to ask ourselves if these analogies are still helpful. Alas, we probably won’t be trading derivatives of tech debt anytime soon, but hopefully we understand our tech debt risk profile a little better.
