TechnicalDebt

c2.com

21 points·cshekhar··6 comments

I prefer the unhedged call option analogy: http://www.m3p.co.uk/blog/2010/07/23/bad-code-isnt-technical...

- Debt is predictable: if I know the price in the future, and the rate of interest, I know the price now. If I knew what the cost is going to be in future, I could come up with today's price for the bad code and make perfect decisions.

- Unhedged options either blow up (incur a large future cost) or they expire worthless (I escape without paying anything). I don't know in advance which outcome will happen, so in today's price, I have to consider both possibilities and factor in the uncertainty.

That's a more accurate metaphor, but it's not usually better. There's two reasons to employ the "technical debt" metaphor - to get programmers to think about the issue, and to explain to external stakeholders why you need time for technical issues.

As a quick shorthand, "technical debt" works better than "technical unhedged call options" - and if you need to go back and explain what the hell is a call option, then you've lost your audience. Everyone understands the concept of debt already.

Maybe I should have pointed out that I work in derivatives...

I think your version is the better way to explain things to non technical personnel, like any kind of management without any programming experience.

Reply on news.ycombinator.com