

TechnicalDebt - cshekhar
http://www.c2.com/cgi/wiki?TechnicalDebt

======
timrobinson
I prefer the unhedged call option analogy:
[http://www.m3p.co.uk/blog/2010/07/23/bad-code-isnt-
technical...](http://www.m3p.co.uk/blog/2010/07/23/bad-code-isnt-technical-
debt-its-an-unhedged-call-option/)

\- 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.

~~~
tmorton
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.

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

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

------
Peroni
Related: <http://fragile.org.uk/2011/01/how-i-manage-technical-debt/>

------
mgunes
Related: <http://news.ycombinator.com/item?id=2336008>

