[gilfoyle]

There is intentional or incidental technical debt which is debt taken for good reason because of lack of enough context, YAGNI, or whatever with the understanding that it will need to be revisited and the developers are aware of it. This one is easier to deal with and is usually contained well because it is a known-known.

Then there is accidental technical debt that is mostly due to lack of design skill / judgement that results in code smells, spaghetti code, poor abstractions and a codebase that sucks the life out of everyone.

When most people write about technical debt, they refer to the former while it is the latter that is much more costly and prevalent and yet, avoidable.

[herodoturtle]

With a name like 'gilfoyle', I'm compelled to remind you that son-of-anton's debugging capabilities proved rather useful at creating a third category of technical debt - namely technical debt resulting from unintentionally deleted code.

[Noumenon72]

I looked up this Silicon Valley reference:

https://www.idginsiderpro.com/article/3488819/is-that-you-or...

[hinkley]

> YAGNI

Because code is written by humans, it behaves in ways that are not too much of a stretch to call “organic”.

We need more literal and figurative gardeners in programming, but everyone is a hurry to get their 10k hours in before they learn how to adult properly.

Gardeners make suggestions to plants, but the plants end up doing their own thing about half the time, so everything becomes a negotiation. When you try to assert your will too hard, you can kill the plant.

If you’re pruning a tree, the tree reacts by putting out more branches. If you do it too aggressively, the result is an ugly, unhealthy tree. If you stay below a threshold, everything keeps working as expected. So you have a pruning budget every year, and renovating a tree nobody has maintained may become a four or five year project.

The first year you cut off the sickly branches, and the one you keep walking into. Second and third year you do preventative maintenance, removing crossed branches and bark inclusions (future calamities). By year three you might begin making aesthetic decisions, and by year five you either finish up or start over because the tree has changed so much in the last four years.

Like software, usually this plan is in your head, not on paper. But for software it doesn’t have to be this way, we just haven’t done anything about it yet. I hope that 15 years from now we have ways to record code reviews not attached to PRs, noting targets of opportunity and storing them with the code. That way, when I’m adding a feature I can also look at the refactorings suggested by others, especially the ones that are not locally apparent, like architecture and code duplication issues. Having to fix a problem the moment you see it is a very ADHD mode of thinking.

[freespirit77]

Even the first one can become an issue if the follow up refactoring is not prioritized and the team moves on to the next feature, the POC becomes a Product. It needs discipline to make sure the follow up investment happens.

[kerblang]

I would refer to the latter as "technical death", as in a terminal disease you never recover from, because it comes from an incurable culture of dysfunction. I say "incurable" anecdotally, and I'd like to be wrong about that, but I suspect I'm not, and maybe it's better to recognize you're swimming against the current and just get out of there instead of hoping to pay off this idea of debt someday.