Hacker News Reader

Comment by andi999 | Hacker News Reader

I think the term 'technical debt' is not good. It creates the wrong mindset if you talk to a business person, since they probably get into the mind frame of 'financial debt'. Why not call it 'we have been cutting corners in the software architecture'; I think people will understand that analogy better.

View on HN

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.

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?

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.

I like the term because it is like financial debt, and is a good way of communicating the problem to a business person. The debt will need to be paid off at some point, the longer you leave it the more that is going to cost, and it costs you even if you just keep paying the interest. Framed this way, it also helps us explain why many business people don't care. Many will only care about the projects they are currently responsible for and not about next weeks or the ongoing health of the company. With luck, paying the debt will be somebody else's problem. If you called it 'cutting corners', you get a pat on the back for keeping costs down and expected to do it more often. You might even get a bonus if your boss doesn't take the credit.

Well, if too many corners are cut, people understand it as well 'for this feature we have to fix the architecture, we have been cutting too many corners, so otherwise the whole thing will crumble' makes it pretty clear. Also it term makes it clear why the state is as it is (since cutting corners also 'solves' problems). How do you explain why engineers would have been allowed to take on debt on the company?

Investor: "If developers have debt, why don't they simply repay it? They could pay in install-ments."

Bigger question:"whom do they owe the debt to?" - "to themselves" - "oh, then just strike it off"

of course thats a silly answer: "to the code base" - "who owns the code base" - "the company" - "well then lets just get rid of that 'code base thingy'"

Well if you delete the codebase you no longer have any tech debt, problem is technically solved. Big brain time.

Exactly. So obviously the code base is an asset. If one then want to define technical debt it is more like the difference of the value of the code base compared to the imagined/perceived value of the code base. But this does not help with anything as well, since you could also just adjust the perceived value of the code base to reduce technical debt.

You cannot reduce the perceived value of the codebase in most cases since the value is already communicated with the customer, there might even be contracts, and SLAs.

> compared to the imagined/perceived value

I guess the word you are looking for is "necessary".

Reply on news.ycombinator.com