Bad code isn’t Technical Debt, it’s an unhedged Call Option
Written on 23 Jul 2010
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 santas1 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.
Filed in: Agile Programming, Software culture.
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.
Your new metaphor sounds good, but I’m not sure I like it better than technical debt. I guess I’ll have to try it and see as my listeners react
But I agree with you that debt is not the same as bad code. You should check Ward Cunningham’s video on this: http://www.youtube.com/watch?v=pqeJFYwnkjE
Cheers!
[...] This post was mentioned on Twitter by SteveF , Chris Matts. Chris Matts said: RT @sf105: Just wrote up "Bad code is a call option" http://bit.ly/bVjsLE @natpryce @PapaChrisMatts [...]
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.
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.
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.
Good metaphor and good post.
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.
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.
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.
@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.
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.
@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.
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.
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.
@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.
[...] Bad code isn’t Technical Debt, it’s an unhedged Call Option – Call options are a better model than debt for cruddy code because they capture the unpredictability. If I slap in an a feature without cleaning up then I get the benefit immediately. 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. [...]
[...] for testing. The blue card is some sort of “Technical Debt” you are incurring btw (Or Unhedged Call Options as some Agile thought leaders are starting to see [...]
[...] weekend, after reading Steve Freeman’s “Bad code isn’t Technical Debt, it’s an unhedged Call Option” in which he advocates the theory that bad code compares to financial instruments that can [...]
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,
Leo.
PS.: Also currently reading your book…
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.
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.
@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.
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.
@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.