Steve Freeman Rotating Header Image

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.

Payoff from writing a call.

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.


  1. LR says:

    Why is it that software folks always try to use analogies from software or art? Isn’t the economy kind of like a bad piece of software … it crashes all the time :)

  2. Scott says:

    The metaphor has a real flaw in it.
    Options expire.
    Unpaid debt lives forever.

  3. […] debt, just like its financial cousin, has the nasty habit of compounding. If you don’t pay it down regularly, then the ultimate […]

  4. […] restricted the more debt we are carrying.  A principal developer recently sent me a blog called Bad Code isn’t technical debt, it’s an unhedged call option which explains this concept […]

  5. Good stuff. However, a couple of issues come out of this.

    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.

  6. @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.

  7. […] been some writing lately on metaphors for technical debt which has caused me to think about what it means to […]

  8. […] a financial institution they even get the notion that bad code isn’t so much a debt as an un-hedged call option, but they also recognize that it’s much easier to explain (and say) “technical […]

  9. […] 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 […]

  10. […] 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 […]

  11. […] seguir coloco com autorização do autor a tradução do post  de Julho de 2010 do blog do Steve Freeman com outra analogia muito boa sobre débito técnico. […]

  12. […] in software design one can often slow a slide to rigidity by refactoring code, such as by looking for better abstractions to achieve modularity. But the brain probably already […]

  13. […] Wochenende ist mir der Blogbeitrag Bad code isn’t Technical Debt, it’s an unhedged Call Option von Steve Freeman wieder zwischen die Finger gekommen. In diesem Artikel beschreibt er sehr schön, […]

  14. Dylan Thomas says:

    @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.

  15. […] 2014-12-21 by VINCENT YU in category Science with 0 and 0 Home > Blog > Bad code isn’t technical debt, it’s an unhedged call option Source link […]

  16. Nick Wade says:

    @Dylan Thomas:

    in other words, to discuss risk management rather than cost saving.

    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.

  17. 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.


  18. You can merge my comments, forgot to share one article with you about Taleb and his endeavors

  19. Kevin says:

    I love both metaphors, but really it just gives managers more to not think much about. It does offer us some catharsis though.

  20. Garrett Smith says:

    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.

  21. […] Bad Code Isn’t Technical Debt, It’s An Unhedged Call Option […]

  22. […] 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. […]

  23. […] Bad Code Isn’t Technical Debt, it’s an Unhedged Call Option (Steve Freeman) […]

  24. […] Debt, it’s an unhedged Call Option – Steve Freeman.   Retrieved 21/07/2013, from Gourly, R. (2013). Technical Debt and Interest.  Retrieved from […]

  25. […] 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, […]

  26. Quora says:

    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…

  27. […] For this, consultants are great. Mostly because they help reducing your technical debt by offering a roadmap of how to solve issues. Also, especially if the startup has only one software guy, having an extra pair of eyes on your activities can really hedge you for future surprises. […]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>