[GuB-42]

It is essentially the same as financial debt, too much debt and you go bankrupt, but if you refuse to take some debt, you may lose opportunities.

The main difference is that technical debt is hard to quantify. Financial debt is obvious, you see the numbers, interest rates, etc... You see how much repaying your debts will save you money. Technical debt, you know it is there, but you can't easily put a number, you don't know exactly how much it will cost repaying it and how much "interest" it will save you when you address it.

[andi999]

It is not the same. Financial debt has to be on the balance sheet; technical debt is not. My point is the a finance/business guy will think in the totally wrong direction with what you actually mean. Also to whom do you repay technical debt?

[tsbischof]

It really should be on some form of balance sheet, in the form of "costs to implement new feature" (debt gets repaid in part by the next customer) or "costs to maintain" (ongoing interest payments that come out of overhead). The big issue with throwing around terms relating to complexity without assigning projected value or probability distribution for that value is that it makes any discussion asymmetric. As someone who knows something about the processes involved but does not have deep knowledge of the code base, it is impossible for me to accurately predict the tradeoffs in discussions. So when we do have to build project plans and discuss tradeoffs, I have to either rely on the people doing the work to build one-off projections or otherwise make things up the best I can based on general patterns.