[morgelgluff]

My pet issue with technical debt, is what happens when engineers are allowed to pay it down.

In the best case people embark on well-informed yet insane ”version 2.0” over-engineering binges. This can be nice, but is often a waste of time.

Quite often the ones who cried “muh technical debt” in every meeting simply did not understand the problem being solved by the debty code, and end up making something novel but equally problematic.

In the worst case, you have a combination of ignorance and best-practice-hysteria that gets applied to actually-fit-for-purpose code. Then the 200 lines of performant and correct code that takes two hours to fully understand, gets turned into 2000 lines of deeply nested class hierarchies mixed with immutable FP-wank that takes several days to get a grasp of and both fails to handle real-world data (“not in the specification!”) and tanks system performance (“premature optimizations!”).

[AstralStorm]

That's what you get from inexperience not from paying off the debt.

It's called second system effect and it's relatively easy to avoid by methodically documenting original and mercilessly avoiding adding features.

And this includes design features that are not immediately shown to save a lot of time and code. Every such feature needs an advocate and also a prosecutor, and alternatives have to be briefly explored using a prototype.

The worst mess is actually trying to pay off the "debt" in installments by taking on new one. Then running out of time or shifting focus, ending up with double the problem and half the readability.

[morgelgluff]

Those observations pertain specifically to developers who howl about vague technical debts. Those tend to be juniors.

Seniors point out specific issues with specific consequences and lay out specific actions to resolve/mitigate. The term “technical debt” isn’t usually needed in that case.

Technical debt terminology is a fig leaf for “I dont understand and I wont put in the effort to learn”.

[Dylan16807]

The best case is a series of small refactors that split up modules that do too many things and combine modules that always work together and don't benefit from the separation. And most importantly to reduce pieces of code reaching in to the internals of other pieces.

There is no need to do a 2.0, and the number of lines of code will often drop. Though that depends on how much edge case handling code was skipped in the debt version.