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.

63 replies on “Bad code isn't Technical Debt, it's an unhedged Call Option”

  1. neat thinking, thanks for sharing… my one thought as feedback is that people may get confused about whether one is buying or selling the option. the default thought when hearing an option could be to think that one is buying the option, so perhaps there is another iteration needed on this concept, from a commmunications standpoint.

  2. Having previously studied calls and puts for fun, I get it. It’s a much more accurate representation than technical debt, but I don’t think that it’s as easily understandable.

  3. Thanks for responding. The usefulness of the metaphor probably depends on whether you’ve working in financial markets or not, where these terms are common currency.
    As I said, the thing I like best about the idea is that it expresses the unpredictability of software development.

  4. like +1
    This is thought provoking, but I’m not sure this can totally replace the debt metaphor.
    First, there is not unbounded downside.
    Second, the option metaphor implies two discrete events, first the purchasing of the option at a fixed price, and then the choice of exercising the option. Neither of those events really make sense to me in this context.
    Poor code tends to be produced by accretion of decisions and entropic forces, which, in my opinion, parallels undisciplined credit card purchases more than an naked option. Further, debt continues to grow without effort to pay down the principle, while the value of an option is mostly reflecting external circumstances.
    Interesting to ponder though.

  5. Awesome, this really works for me. Technical Debt metaphor always seemed lacking to me. The fundamental point is the unpredictability and this metaphor captures that perfectly. I will use it from now on. Thank you Steve and Chris.

  6. Very nice – I’ve heard Chris mention this sort of stuff, but it’s nice to have a post such as this to point people at.
    I’d also be interested to see if anyone has thought of any financial analogies for comparing co-located / cross continent development teams. Something that’s going to become very relevant to my current team.

  7. I like this metaphor a lot more than technical debt. I concur, through experience, that using the word ‘debt’ can indeed cause confusion when talking to the folk who understand debt, usually the stakeholders; these are the very people who need to comprehend the scale of the decision they are making. Calling it a technical unhedged option call will get the appropriate response. Technical naked call seems to have the best ring.

  8. @Andrew. Of course, it’s not a perfect metaphor, but it can take the conversation in interesting directions. To be clear, bad code means “selling”, not buying a call option. I take the money (functionality) now, but might be called on it (required to extend it) later.
    if you think of each little bad code decision as a sold option, then the system as a whole can be thought of as a portfolio that can be pushed into failure by a sudden shift in the market (major new requirement). Or it might do just fine and the owners collect the money.

  9. Hi Steve,
    I agree that the metaphor works better than the technical debt metaphor. However, I worry that many people outside of the finance world will struggle with it.
    Perhaps the technical debt metaphor could still work but instead of the lender always being a dependable source like a bank it could sometimes be a loan shark.
    So, cruddy code without tests gives you a benefit in the short term, you take out a loan with the Loan Shark. And for all the other times you take a shortcut, you take on some more debt from the Shark.
    However, sharks are unpredictable and volatile and once you’re indebted they are in the habit of changes the rates of interest to keep you so. They also decide to call in the debt when they see fit, not on your own time schedule.
    Some types of technical shortcuts are shortcuts to the bank, some are to the Loan Shark.
    I can’t see anyone arguing that Loan Sharks are a good way to manage your finances. If we can just identify where shortcuts lead maybe the technical debt metaphor still has legs.

  10. @Ed We probably don’t have to introduce loan sharks, some of the banks are quite capable on their own 🙂 The relevant part of the technical debt idea is probably compound interest, the point that bad code on top of more bad code just runs away eventually. And that things can get much worse when interest rates rise. That said, if a system just works and doesn’t need more than minor tweaking, then the debt metaphor doesn’t work so well.

  11. One of the most original posts on code quality I’ve seen for a while.
    What I find interesting is that here in London there are a bunch of people applying financial analysis to the questions of software development. Quite natural really, this is the place where software engineers and finance meet. O, and we have Chris Matts too.
    While the analysis is good the problem with this approach, which Ed suggests but doesn’t say explicitly is: it is actually more difficult to explain the metaphor than the problem.
    If you have an audience which understand options than fine, they get it but actually, most of the world doesn’t so you have to explain it from scratch.
    The insightful bit here is really the risk analysis bit. Its all about risk management.
    The standard risk management tools of project management are too simple: make a risk log, catalog your risks, classify them (accept, mitigate, etc.). This approach ignores the fact that risk leads to profit, eliminate the risk and your eliminate the profit.
    The option based analysis brings risk and profit closer together.

  12. How about a metaphor like this? Skipping refactoring is like skipping the regular maintenance of a car. You can never know when something will break – knowing Murphy it usually happens during a long vacation trip when you’re in a country where there are no spare parts for your car. Although a new car will last a couple of years without maintenance, but with software the mess will strike back much sooner.
    Maybe the metaphors about housekeeping and doctors washing their hands are still better. They are at least easy to understand and their implications are strong and imminent enough.

  13. @esko. I expect that even car maintenance could be modelled as options. But, again, the difference remains that it /is/ possible for really bad software to work fine provided it doesn’t need to be changed.

  14. Hi Steve,
    In a field in which a good part of what is around is just noise or repetition of old concepts rebranded as new things, your post is really unique and interesting.
    Your post gave me a few insights that I also blogged about.
    Thanks for that,
    PS.: Also currently reading your book…

  15. There is an interesting thought you have at the end of the post. It would be useful to think about how to arrive at a Mark to Market figure for code ( and thus code smells).
    Can it be done by cost method i.e. calibrating effort spent with test coverage
    Can it be done by option valuation method i.e. the amount of flexibility it offers at a point in time for change in requirements
    Can it be done by percentage completion method i.e. percentage completion of overall business case
    Looks like more pints will have to be poured into Chris to get the answers.

  16. Nice idea, but I still prefer the debt analogy. It seems to me that the option analogy has two flaws:
    – introducing technical debt is almost never free. Yes, you might “never see that code again”, but actually, someone will probably read it at some point just to work out it isn’t the bit they want to look at. This is particularly true once you skimp more than once. Other technical debts like missing tests also cost. In general, I’d say there’s an overhead on living with most technical debt.
    – the exposure isn’t unlimited – essentially the exposure is this ongoing overhead plus the potential need to eventually fix your code to be the way it should have been in the first place. This might be more than it would have been if you’d done it right in the first place, but isn’t unlimited.
    So, not an option, but something where you have to pay an ongoing amount each month, only ending when you pay a large amount at the end. Actually, that’s a debt, on which you make interest payments until you eventually pay off the capital.

  17. @Dave. Agreed, it’s not a perfect metaphor, but then neither is debt 🙂
    – my point about never seeing some code again is slightly ironic, since it’s quite a strong condition (although it does happen).
    – there are a couple of ways at looking at the exposure. One is that, eventually, the system can’t handle the changes needed, which is equivalent to going broke. Another is that a system is a portfolio of many small options, each of which may prove locally expensive building up to a general drag on making progress.

  18. Steve,
    Well done. I’d been puzzling over “Technical Debt” for the past couple weeks and concluded that the debt metaphor might sometimes push people to do the right thing, but there were two big problems.
    First, the metaphor is imperfect, very imperfect. Technical issues usually don’t behave like debt, they are less predictable.
    Second, the Ward video cited by Filipe specifically calls out Lakoff as the inspiration and discusses current conflation of strategic release decisions and cruddy code. Ward created the debt metaphor to guide peoples thinking. But debt It is likely mean different things to different people. In hindsight, applying the concept of debt to cruddy code as well as or rather than a conscious strategic decision to release before finalizing the requirements (with all that implies) becomes a feature, not a bug.
    As for the power of metaphor, I think Cunningham bought a pig in poke. In archaic English a “poke” is a sack, an unscrupulous merchant might offer you a young “pig in this poke”, but later the unfortunate buyer opens the bag you discover a cat not a pig. Check first and you “let the cat out of the bag”. Both turns of phrase persist in our language despite few recognizing, even unconsciously, the metaphorical origins. We should be conscious of the distinction between metaphor and abstraction.
    All models are wrong, some are useful. [Box] I prefer to use metaphor to help people “get it”, then explain a more precisely defined approach using life cycle models and risk tracking.

  19. @Bill, thanks for your comment. As Chris Matts pointed out when he came up with this, different people think of debt in different ways. Some people are scared of credit card debt, some people pile it up.

  20. It’s a good metaphor.
    Those commenters who suggest that it may not be easy to understand outside of the finance world should remember that this is the nature of metaphors; if you are trying to explain something to someone and decide to use a metaphor, you need to choose one in a domain they understand. Different people need different metaphors.

  21. My only concern is that in reality risk managers don’t always hedge an option. They might take a view on the direction of the market, perhaps hedging partially or later as that view changes. It saves the cost of the hedge
    If that same manager is then our customer as we apply the metaphor to real world delivery he could take that view again. Especially as we won’t really need to change it later as his requirements are “correct” 🙂
    Nice post though. I like to think about problems in different terms as I often struggle to help the customer understand the realities of delivery. I did once try to convince a desk head we couldn’t just add more developers to do more in the same way more traders can’t price a product faster. It fell flat on its face so if you can come up with one for that as well I’d be grateful.

  22. @Kevin. I think I pointed out that we can choose not to hedge and save the premium–and take any consequences. Unfortunately, most software dev organisations don’t have a risk management group.
    I’ll see what I can do about the other metaphor…

  23. Regarding technical debt:
    I think it’s a better metaphor than “unhedged call option” for a few reasons: 1) as others have pointed out, it’s easier to understand, 2) like a monetary debt, a technical debt is not a problem and may be better than the alternative, but only in small quantities.
    What I mean by 2) is is that it may make more sense to work on other aspects of the project, new features, etc., than to fix some small problems in the code. One should recognize the problems, and keep a list of them, but as long as they remain small they are not a problem. Like monetary debt, technical debt only becomes an issue when it grows to a point where it becomes an impediment, a problem.
    Finally, addressing some posters point that debt is more predictable than an unhedged call option, small technical issues are a lot more predictable than they are once they grows large. It’s when you don’t know how you can pay off that credit card that it’s a problem.
    Cheers, and missing the Old Bank of England…

  24. @Mike
    1) easier to understand depends on your audience. In the world that Chris and I inhabit, these are common terms.
    2) I wasn’t thinking of an entire system as a call, but as a portfolio of calls, each of which represents a drag on change. Most of them won’t be too expensive on their own, but when there’s a sudden shift in the “market” (a major new requirement) many options will get called at once and we’re in trouble.
    And, remember folks, it’s just a metaphor.

  25. Steve,
    I just came across this, nice post. Your comment (reply to Andrew) with the few additional sentences of explanation really helped me clarify.
    Could you be persuaded to incorporate (a version of) those explaining sentences in the post? I believe it would really make your text easier to understand.
    Best regards from Sweden!

  26. @Dusty – aren’t metaphors and models useful to get people thinking?
    @Mike – I also work in finance (sometimes) and people get this really easily. I also present estimates as probability spreads. The finance people eat this up.
    I think Steve’s last point is valid. It’s a metaphor. No more. No less.
    My latest idea in the area of TD:

  27. Hmmm… I think technical debt is still a better model, because there isn’t anything that you’re necessarily going to be required to deliver in the future.
    However, you have to be clear that technical debt has an inherently unpredictably adjustable interest rate (the amount of refactoring you’ll continually have to do to “service” the code). Worse, the interest rate is proportional to the value of your code, so the more you expect to get from your flaky coding, the less worth it is is to code flakily.

  28. The story about santa chocolates may be apocryphal but the story about the coal delivery may not be:
    And of course not believing everything I read on the net I went
    looking for any signs that this is an urban legend. It isn’t listed on like most other urban legends. And:
    suggests that it may be possible. 4% of commodities traded are
    delivered. It seems to me the most suspect part of the coal story is
    that the logistics of having actual barges delivered would have been
    worked out and carried through without anyone notifying the recipient
    but as was pointed out that was a location which until the past few
    years actually had received such shipments so…

  29. Sullivan, K. J., Griswold, W. G., Cai, Y., and Hallen, B. 2001. The structure and value of modularity in software design. In Proceedings of the 8th European Software Engineering Conference Held Jointly with 9th ACM SIGSOFT international Symposium on Foundations of Software Engineering (Vienna, Austria, September 10 – 14, 2001). ESEC/FSE-9. ACM, New York, NY, 99-108.

  30. Good code is also a ticking time-bomb when there is not enough documentation for figuring out the code.

  31. Steve/Chris, I really like metaphor. I think we’d all do well to learn more about the world of finance anyhow. Unfortunately, many agilistas fail to accept that there risks and costs to be weighed up. As Allan said – it’s all about risk management.
    As all seem to agree, the metaphor is useful but not perfect (as is the way of metaphors). One area where the metaphor seems to fall down is the expiration date – the fixed date in the future that the naked-call writer breaths a sigh of relief – they’re in the money :). The expiration date for software isn’t fixed and is another risk/unknown. Some software sticks around a very long time (cobol banking software), whereas other bits of code are short-term by nature (data migration scripts) and still others – say in startups – are hoped to last a long time but are quite likely (on probability) to disappear as the company fails. There is a cadence at which we might expect to rewrite or port to another language or technology platform – perhaps every 5 or 10 years. This cadence could kinda/sorta amount to a default expiration date for the software. However, different companies/projects will have different policies on rewrites/port/platform-changes.

  32. Pingback:
  33. I have to say as someone who writes code for a finacial company that this is spot on and I plan on using this the next time they want some radical change and not give us time to test things.

  34. If we are going to dip into the financial space, let’s call technical debt what it really is–a call spread. The spread caps your downside which seems little more accurate. Additionally, the premium (benefit) you collect for selling it (writing bad code) is much smaller. Just my two cents.

  35. 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 🙂

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

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

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

Comments are closed.