[elpakal]

Is tech debt subjective? I've worked on different teams that call anything from wrong grammar in comments to incorrect capitalization of a var name tech debt. Wondering if it follows that more code = more debt because more people have opportunities to disagree about how something was done.

Asking for a friend.

[coldtea]

All of these are debt. They only subjective part is how much of a debt they are.

But bad comments (even if it's just grammar) and misspelled variables are indeed part of debt. To see whether something is debt or not, imagine it piling up everywhere in the code.

What if 60% of variables in the code base had "incorrect capitalization"? What if most comments had the "wrong grammar"?

It would be more difficult to understand, refactor, and extend the program. Well, that's debt.

Debt can be negligible when it's like one dollar, but it can creep up and accumulate if we let it.

Also think of the "broken window" theory. Sloppy comments here, mistyped vars there, give a signal that "everything goes".

https://en.wikipedia.org/wiki/Broken_windows_theory

[Shaanie]

Do you disagree with the notion that misspelt comments or variables is technical debt, though? Personally I would consider it a light form of technical debt simply because it makes the code slightly harder to read.

[SifJar]

It not only makes it slightly harder to read - it can also make it slightly harder to modify.

For example, if all variables in a code base are camelCase but one variable StartsWithUpper, chances are every time you reference that variable in a future code change you'll call it startsWithUpper and then hit an error (depending on the language, either at compile time or run time), and have to go back and fix it. So it adds a little time to development in that way. Negligible, but non-zero

[xkcd-sucks]

If it causes a problem where solving the problem once doesn't solve it in the future, and where the fixing is a total waste of life that doesn't teach you anything, or where an easily solvable problem is compensated for in higher level abstractions, it's probably "tech debt".

Personally I would consider a stupid name or out of place capitalization to be tech debt of it leaks out into config parameters or something such that it can confuse more than just the people looking at one isolated chunk of code.

(Or call it "tech necrosis", because americans with college debt tend to view "debt" as an inevitability in life and that's not a helpful attitude for getting stuff done)

[squant0]

I like to compare the nominalization of technical debt to taking out bank loans and investing in the open market.

All tech debt, like loans, have some interest rate. Some debt has a great rate, say 3%, and other debt has unmanageable rates, say 18%. Once we attain some stability to begin paying down our debt, it's necessary to pay down the higher interest debt (architecture, libraries, speed, etc.). Once we whittle our way through the high interest bearing debt and we're left with low-rate rate, it may make sense to continue investing new capital into the market (novel product/feature development). The new investment could return 8-10% annually, which garners higher annual net returns (10-3 > 3) than continuing to pay down all debt.

TLDR: Some technical debt affects critical systems and flows and need to be paid down immediately. Some technical debt may be cosmetic or semantical, therefore less critical and can continue to accrue interest.