Hacker News Reader

A lot of what is called "technical debt" is really developers coming in after the fact, looking at messy, real world code with years of feature build-up and bug fixes in it, and deciding "Ugly, rewrite."

View on HN

A lot of "technical debt" is also messy, real world code that its writers can't accept as being bad because they've dealt with it for so long and can't think about it any other way.

I imagine the intersection of those two sets is much larger than either camp is likely to admit.

A lot of excuses project managers use to ignore technical debt is looking at the opportunity cost of building a new service vs refining an old service and saying "fuck it" and then conceptualizing their choice after the fact as a wise economic decision, then coming back to the problem after it becomes serious, then hiring someone fresh out of college to "fix it" because that's way cheaper then having the original engineer or a professional deal with a tiny fraction of exceptions the right way.

Then they move on to a new job once the debt becomes untenable. This works quite well (as an "economic" strategy) for industries of all types. I bet you can think of a few.

No need to move on, just declare bankruptcy. The executives and unions do just fine sticking it to the investors in the airline industry.

Reply on news.ycombinator.com