The concept of technical debt has been well-known in computing for many years. It has been the subject of research by practitioners and academics. It’s been chewed over pretty well. But my CTO recently shared an article that suggests debt is a poor model for bad code.

Steve Freeman proposes hedging options as a better model. Debt is too structured and predictable. Call options are inherently unpredictable. Debt will accrue at a defined rate and you can figure out (assuming an accurate model) what payments will look like. Options can be ultimately profitable or ruinous.

Freeman’s analogy makes a lot of sense. It’s probably truer to reality than the more simple debt model. But as the excellent comments on that post pointed out, it’s less approachable to people without a background in finance (which is probably most IT managers and even more developers/admins/etc). Technically correct is the best kind of correct, but there’s a lot to be said for being understood.

Quantifying the cost of bad code remains a challenge, particularly when the badness is situational. So whatever gets people thinking about the longer-term consequences of design and implementation is a good model.