[briandear]

It isn't that complex. The idea behind the metaphor isn't to communicate what an uncovered call is, it's to illuminate what technical debt really means. It's a philosophical analysis describing that "debt" isn't an accurate metaphor for what techical debt really is. The fact that this way of thinking about techical debt "isn't widely known" is exactly the point. Most folks think about techical debt in terms of a thing that must eventually be repaid regardless of the future of the software while presenting it as an uncovered call is much more accurate as to what is actually happening: you're trading a now benefit for the future potential that it will cost you nothing or it could be so expensive that it might cost you everything. The decision to incur technical debt is actually an investment that the benefit now is more valuable than the future cost. Debt is completely different; debt implies that it must, eventually, one day be repaid with interest; however not all technical debt must actually be repaid-- for example if you build feature x in a sloppy but expeditious way, you've incurr d techical debt, however if feature x is eventually depreciated the you "won" because your overall cost of the feature is less than it would have been had you not incurred the techical debt. But, if feature x becomes the center of your product's world and everything else is blocked by the debt, then you lose greatly in comparison to the cost it would have taken to build it debt-free in the first place, thus the risk is theoretically unlimited and not just limited to the amount of technical debt incurred -- because other things are now being delayed because of that debt. So the goal, in my opinion is to manage risk, incur technical debt minimally and only when there's a high probability of that debt not ever having to be repaid. If you know, with a high degree of certainty that the debt will need to be repaid, it's cheaper not to incur it in the first place.

I think the uncovered call metaphor is a brilliant way of framing this issue. It doesn't matter if we know finance or not, it's the way of looking at the problem that provides us with a good framework with which to make development decisions. If we are aware of the unlimited downside and manage that risk, we can actually be more aware of when it makes sense to incur technical debt and when it doesn't. In my opinion, it, just like options trading, is all about risk management and certainly not about traditional debt management.