[theamk]

I agree with general sentiment that people mean different things by "technical debt" but don't buy the argument for the title.

Article says: "Debt repayment has three properties that are straightforward to grasp — principal amount, interest rate, and term [...] when comparing technical debt, there is no agreement on the principal, [...] there is no concept of an interest rate [...] , term length isn’t a fixed concept"

However, there are generally accepted meanings of the those terms for the technical debt:

- The "principal" is how many things is wrong with the code. It could be measured in features ("We need to implement unit tests and database layer to clear technical debt") or in time ("it will take 6 FTE-months to clear our technical debt")

- While "interest rate" is rarly used, "interest payment" is common -- this is extra time spent implementing the new feature. One can say: "This feature would take 1 day if we had database layer, but because of technical debt we own, it will take 4 days instead". In this case "3 days" is the "interest payment"

- Not all debt has fixed term. "revolving debt", like a credit card, has no term at all. Technical debt is like that as well.

(Of course getting the actual values for "pricipal" and "interest payment" is very hard and no two people are likely produce the same estimate for them. But even if don't know the values it does not change the fact the the terms are defined well -- so this is very much a "debt")

As for "not even technical" part: I am going to argue that everything indirectly affects competitiveness, costs, customer satisfaction etc.. A leaking roof will decrease morale, decrease development speed and can even kill the company. Judging by consequences does not really bring anything useful to the table, so if you want to qualify the term, let's use originating action. "Technical debt" if we don't have any tests. "Financial debt" if we took money from the bank. "Organizational debt" if we are not creating the positions we need, and so on...

[stared]

"Interest rate" have also another one meaning in "technical debt".

Even if you don't touch the code at all, it loses its value.

- Developers forget why did they make particular choices, and what were the implications.

- Technologies do age, and there will be maintenance cost for updating that.

[gHeadphone]

You make a god point about the generally accepted meanings for terms for technical debt. However, there are lots of companies ive worked in (and more I know of) that try to scientifically calculate a numerical value for Technical Debt. At best, it's a metaphor, a mental aid to understand a loose concept. Any attempt to calculate implies that there is some 'best solution' that should be achieved. However, this almost never exists, any best solution is in the eye of the beholder, it will differ depending on whether you are a developer, DevOps, client, manager, CISO, barista, best friend, pet.........

[dgb23]

That’s because abstraction enables a mental model and a language around the translation of your domain to computation.

When people dont understand or agree with a model, then you get these conflicting perspectives on what constitutes correct or incorrect expression.

In some simple cases it’s clear that there is a problem, or debt, when there is a clear semantic violation, a code smell or similar. But often there are multiple ways of expressing the same.

Quantification of unnecessary complexity can only be done after you know what is necessary and how you express that.

[jjk166]

While there may not be some universal best solution, that does not mean all solutions are created equal. You can certainly look at two options and say "this one will take about half as much effort to fix later" or "it'll take as much time, but we can put a less skilled person on it." Maybe putting a number on it doesn't mean anything in absolute terms, but it's still useful in relative terms.

[tylerhou]

> "This feature would take 1 day if we had database layer, but because of technical debt we own, it will take 4 days instead". In this case "3 days" is the "interest payment"

Nit: Not the entire 3 days is interest in this analogy because you are also paying down principal.

For example: "Implementing the database layer properly would have taken 5 days; because we took shortcuts (for business reasons) it only took us 3 days. Now we have to implement feature X, and because of our previous shortcut feature X will take 4 days, so 3 + 4 days in total. But if we had implemented the database layer properly in the first place the new feature would have only taken 1 day, so 5 + 1 days in total."

Then in the three-day payment, two are towards principal (that's how much you "borrowed" previously), and one is towards interest.

[codesections]

> Nit: Not the entire 3 days is interest in this analogy because you are also paying down principal.

I didn't read the GP as saying that they were paying down principle. They don't say what the hypothetical feature is, but my assumption was that it's a feature that they could implement without a database layer but that would be faster if they had a database layer. That is, I assumed that even after the 4 days of development for the new feature, they still won't have a db layer – which is why the extra three days is pure "interest".

[hamstergene]

Bankruptcy metaphor is applicable too: when enough debt accumulates, all the capable engineers start leaving the team, and newly hired once never stay for long. The project will either get scraped as unsuccessful, or rewritten/replaced with another one.

This is why it is important to refactor dangerous system deficiencies sooner. If tech debt takes 2 weeks to clean, one can always squeeze that into the plans. If tech debt takes 1 year to clean, it is nigh impossible to persuade the business give that much time.

[amelius]

Nice analysis, but I think you missed the most important difference between real debt and technical debt: with real debt you owe someone else; with technical debt you owe yourself.

[romwell]

Not to yourself; you often inherit the debt from previous developers (who may have left).

The project accrues technical debt.

And it owes it to the users.

Because, ultimately, that's who all these FTE hours (the currency borrowed!) are going to.

By taking a shortcut now, you make an implicit promise to the user to rewrite things later (on behalf of the project).

It's the user that suffers if the debt is not repaid (by experiencing bugs, missing features, slow releases, paying for higher headcount to fix bugs, etc).

Shortcuts don't become debt unless the user is affected. If it's stupid and it works, it's not stupid.

And it is the user that will dump your project if that debt is never repaid.

The debt analogy holds water.

[jameshart]

I had an aha moment a few years ago when I realized that technical debt is not taken out by the development team; the development team are the ones making the loan. The debtor is the product/sales team, who got their feature early but now have to pay a little more (in delay or lack of functionality) for every other feature.

Ideally, a dev team delivers feature value at a particular sustainable rate. Think of that as your product team’s ‘income’. Now, if the product team needs a feature early, they can have it if they take out a loan - they can have the feature built without sustainable integration into the codebase - but it will reduce their effective income because future feature delivery will be slowed by the friction of the incurred debt - the interest payments.

Don’t let the product owners make you feel like you have to deal with the burden of debt they took out! They owe you the time to clean up the mess they demanded to get their features faster.

[arcturus17]

Not necessarily as it is passed down generations. This is in fact when it becomes more painful.

Regardless, technical debt was always clearly a metaphor. I can imagine many other metaphors where one may owe something to oneself, eg, “sleep debt”.

Who cares if it conforms to the definition of the Bank of England?

[andi999]

Next article could be 'butterfly is not a fly; it is not even making butter.'

[sangm]

When you take a loan out of your 401K, would you consider this "debt you owe yourself"?