In 2010 Steve Freeman published the blog post bad code isn’t technical debt, it’s an unhedged call option. He described how Chris Matts came up with the idea of using a metaphor of an unhedged call option for bad code:
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 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.
This blog post is being intensively discussed on Reddit and on Hacker News recently. Some of the reactions are:
Don't read too much into the choice of term for a metaphor. The debt is not financial, economic, or monetary.
Selecting a less commonly-known metaphor is not improving things. Spend less time trying to describe what's wrong with bad code in more precise metaphors and get to work not writing bad code. We all know bad code is bad. Putting a different metaphor on it doesn't change anything.
[Technical Debt] builds a set of false perceptions about the nature and consequences of hasty software development process. And it is doing this especially among business oriented people, meaning the exact same group who is also allocating resources for a given task.
Technical debt might be a good thing. It might allow you to release a product on time, and collect the benefits while working on elimination of the said technical debt. Very much the same as financial debt.
Real debt is easy to measure, therefore none in their right mind would get loans for 1000% of their revenue with interest eating up a huge chunk of the company's budget. But that is exactly what happens at most places in terms of technical debt.
I agree, the analogy is imperfect, because you don't pay interest unless you need to extend or maintain the code. It's only useful in a world where the codebase in question is under ongoing development, but those are the situations where I've used it. Naked calls work fine as an analogy in the case you describe.
Calling it "selling insurance" is pretty good. People blank if you say "options", but selling insurance captures the immediate small upside with potential massive downside later.
I've been working on a terrible project and even my managers know how bad it is, yet despite all their efforts to explain this to senior executives(need more people to work on it, more time to refactor, etc.), they simply don't want to hear it.
InfoQ interviewed Steve and Chris about using metaphors for bad code and code smells, trade-offs and costs of low quality code, and responsibilities for code quality.
InfoQ: What made you decide to write the blog post in 2010?
Steve: Chris had been using the metaphor for a while. I thought it brought a new perspective to the problem, particularly in financial institutions where I worked at the time, and was a witty idea. I also knew that Chris would be too lazy to write it up himself, so I did it for him.
InfoQ: How did an old article, not much more than a joke, suddenly become so important?
Chris: Metaphors are simply a way of creating shared meaning. Developers use the technical debt metaphor to cause a certain behaviour in business investors and managers. Debt works for some. Options work for some. Its just another tool. Why do people get excited about having a new tool?
Steve: I don't know. I haven't been through this before. I'm impressed by how seriously some of the commenters take it. It's another metaphor, a way of thinking about a situation.
InfoQ: Many people know the meaning of technical debt. Why did you come up with a new metaphor of unhedged call options?
Steve: I've heard lots of definitions, including Ward Cunningham's (the original) which, I believe, was more about partially implemented features than hacky code. Chris's original point was that in certain circles, such as the financial markets, debt is a good thing--it's a tool of their trade--whereas an unhedged option rightly makes people pay attention.
One thing that I think many people have missed is that I was trying to describe a code base as a portfolio of options, each coding choice sells a call. When things change, some of those options get called. Most of the time, that's a marginal cost but sometimes there's a major change and things get really expensive.
Chris: I love this definition by Steve. As a development team you are managing a portfolio of sold call options (technical debt). The cost of repaying the options depends on how likely you are to change that component. This is where Todd Little's concept of "Tornado Maps" is so useful. The product owner gives a long term forecast of the work they think might be done. The team use the forecast to work out where the tornado might land in terms of the technical debt.
InfoQ: You mentioned that debt is predictable and can be managed which makes technical debt less suitable as a metaphor. What about unhedged call option, wouldn’t that metaphor suggest to speculation and taking higher risks with bad code?
Steve: The problem with "credit card" technical debt is that it doesn't reflect the non-linearity of low quality. If I never touch badly written code again, then it's not a problem. On the other hand, a small shift in circumstances can bring about a catastrophic collapse. Everyone in the financial markets knows that not hedging is dangerous, even if they're prepared to take the risk.
The dark side of derivatives has brought down entire economic systems, but there's a light side too. Options can be a useful risk management tool if used sensibly, that's probably why we have records of agricultural futures in Sumer from around 4000BC.
I would love to have a better way of analysing the trade-offs of code quality. I'm not aware of any tools that really do that, but Chris's endless nagging got me interested in thinking in terms of options.
InfoQ: Do you think that things have changed since 2010? Has the ship been turned, or is bad code still causing problems?
Steve: Some things have improved. For example, developers are now more likely to get involved in continuous build and automated testing, which used to belong to other teams. I don't expect bad code to disappear in anyone's lifetime--even if we could agree on what it meant.
Chris: I'm not sure the argument has moved on much. The software craftsmenship community have moved on the concept of "beautiful code", however no one is really talking about where/when we should have beautiful code and where we should be happy to leave the code a bit smelly. The quality of the code is as much a responsibility of the product owner as it is the developers. Demanding beautiful code everywhere will lead to the situation where the business investor does not know where to invest in a clean up. Until the development community starts to take the business investor's view seriously, we are going to continue to see smelly code everywhere.