Bad code isn’t Technical Debt, it’s an unhedged Call Option

I’d been meaning to write this up for a while, and now Nat Pryce has written up the 140 character version.

This is all Chris Matts‘ idea. He realised that the problem with the “Technical Debt” metaphor is that for managers debt can be a good thing. Executives can be required to take on more debt because it makes the finances work better, it might even be encouraged by tax breaks. This is not the same debt as your personal credit card. Chris came up with a better metaphor, the Call Option.

I “write” a Call Option when I sell someone the right, but not the obligation, to buy in the future an agreed quantity of something at an price that is fixed now. So, for a payment now, I agree to sell you 10,000 chocolate santas[1] at 56 pence each, at any time up to 10th December. You’re prepared to pay the premium because you want to know that you’ll have santas in your stores at a price you can sell.

From my side, if the price of the santas stays low, I get to keep your payment and I’m ahead. But, I also run the risk of having to provide these santas when the price has rocketed to 72 pence. I can protect myself by making arrangements with another party to acquire them at 56 pence or less, or by actually having them in stock. Or, I can take a chance and just collect the premium. This is called an unhedged, or “Naked”, Call. In the financial world this is risky because it has unlimited downside, I have to supply the santas whatever they cost me to provide.

Call options are a better model than debt for cruddy code (without tests) because they capture the unpredictability of what we do. If I slap in an a feature without cleaning up then I get the benefit immediately, I collect the premium. If I never see that code again, then I’m ahead and, in retrospect, it would have been foolish to have spent time cleaning it up.

On the other hand, if a radical new feature comes in that I have to do, all those quick fixes suddenly become very expensive to work with. Examples I’ve seen are a big new client that requires a port to a different platform, or a new regulatory requirement that needs a new report. I get equivalent problems if there’s a failure I have to interpret and fix just before a deadline, or the team members turn over completely and no-one remembers the tacit knowledge that helps the code make sense. The market has moved away from where I thought it was going to be and my option has been called.

Even if it is more expensive to do things cleanly (and I’m not convinced of that beyond a two-week horizon), it’s also less risky. A messy system is full of unhedged calls, each of which can cost an unpredictable amount should they ever be exercised. We’ve all seen what this can do in the financial markets, and the scary thing is that failure, if it comes, can be sudden—everything is fine until it isn’t. I’ve seen a few systems which are just too hard to change to keep up with the competition and the owners are in real trouble.

So that makes refactoring like buying an option too. I pay a premium now so that I have more choices about where I might take the code later. This is a mundane and obvious activity in many aspects of business—although not, it seems, software development. I don’t need to spend this money if I know exactly what will happen, if I have perfect knowledge of the relevant parts of the future, but I don’t recall when I last saw this happen.

So, the next time you have to deal with implausible delivery dates, don’t talk about Technical Debt. Debt is predictable and can be managed, it’s just another tool. Try talking about an Unhedged Call. Now all we need is a way to price Code Smells.

1) There is an apocryphal story about a trader buying chocolate santa futures and forgetting to sell them on. Eventually a truckload turned up at the Wall Street headquarters.

The term “metaphor” and “model” are interchanged freely, but they do not have quite the same entailments. It is true that bad code may be better modelled as an unhedged call option — except for the obvious problem of intention (most bad code is not written with the presence of mind and explicit intention of an option). But it is false that it is a better metaphor than technical debt.

Most people know very little if anything about financial options. This is as true of managers (and financially imprudent managers won’t be helped by any financial metaphor or model) as it is of programmers. The one exception to this will be in parts of the financial sector. But for most other individuals, a lengthy explanation and discussion is required to embed the mental model of options into their head so that they can easily and naturally make the connection between financial options and code.

By contrast, debt is a culturally shared and routinely experienced phenomenon that requires little supporting explanation or embedding. If you have to explain the explanation, as you have to with call options, that’s a clue that the metaphor is not particularly strong, regardless of its soundness as a model.

@Kevlin. As you point out implicitly, it depends on who you’re talking to. Chris’s point is, that for a lot of finance people (i.e. the accountants who control your budget), debt isn’t as problematic as it is for normal “retail” people.

One of the purposes of this metaphor is to scare such people into paying attention. In particular, we want to get across the point that bad things can happen unpredictably if we don’t have a good understanding of our situation.

[…] even if that meant making it much more complicated, than to introduce a new collaborator. They sold a Call Option—they cashed in the immediate benefit at the cost of weakening the model. The team would be […]

[…] debt as an “unhedged call option”. Edit: while Chris came up with the metaphor, it was Steve Freeman who described it. He says, “You give someone the right to buy Chocolate Santas from you at 30 […]

@Kevlin. I agree, but isn’t that partly the point? Those “financial types” with whom Steve and Chris are trying to communicate may be more motivated to understand something in their own domain. Perhaps it overcomes the mental block that sometimes prevents people outside the software domain from understanding what goes on within it. The key point, I think, is to change the conveyed impression from “this compromise has a fixed and predictable future cost” to “the eventual cost of this compromise depends on unpredictable future events” – in other words, to discuss risk management rather than cost saving. Sometimes a bit of education will be a prerequisite to such a discussion.

I’m using some of my precious lifetime allotment of allcaps to tell you all… BINGO!

That is exactly the discussion that needs to happen. The metaphor works well – I’ve studied options and option hedging and I’d go so far as to say that refactoring == delta hedging, but whatever – it all boils down to risk management.

You just wrote an article on optionality and black swans (theory) – You might enjoy The Black Swan by Nassim Nicholas Taleb, a book about rare events (eg. market crash) that are caused by a fragility to volatility, a hidden risk that blows up.

Also Antifragile / fooled by randomness by the same author. If you enjoyed one or more of his books, I’d be glad to hear from you.

Ugh. What about expiration? Volatility exposure? What is the strike price in software terms?

Like many software to real world analogies like “Software Architect” it is
a bad one.

I’ve thought the bad code is technical debit like credit card debt is one
of the few apt comparisons. You have to pay interest regularly, you can
pay it down but you can also borrow more. And you can declare bankruptcy
and turn the whole system off.

[…] A recent paper from Google stretches the analogy in its title: Machine Learning: The High-Interest Credit Card of Technical Debt. It focuses specifically on machine learning, but definitely read it if you are interested. A recent blog post challenges if tech debt is really “debt” in the strict sense (you borrow fixed amount and pay back slightly more) or if it has a more complicated structure: Bad code isn’t Technical Debt, it’s an Unhedged Call Option. […]

[…] to talk to users or sponsors or vendors. It doesn’t teach you how to make intelligent use of technical debt. It doesn’t teach you about how to dive into unfamiliar code, under a tight time constraint, […]

What would I need to do in order to calculate technical debt for a software project?

You can’t. Debt is a bad metaphor, because when you write code poorly, you have no idea if or when it will need to be redone properly, how pressed for time you’ll be then, or how long it will take. Debt you know exactly when and how to pay down. A be…