[frollogaston]

I'm fine with the contempt approach. New business priority comes in, and the software can't support it because of tech debt, so someone fixes it.

Otherwise, even if people tackle the tech debt in good faith, they spend endless time polishing things that don't really matter. Something big like a database or API is deeply flawed, and they focus on improving the unit tests, which further entrenches the broken stuff because any replacement now has to meet the same standards.

[awkward]

Contempt is corrosive, and if you're fixing debt in response to business needs that's putting the turnaround on real business needs at risk.

Goldbricking and polishing turds are definitely pitfalls, but the benefit of a low debt codebase is insanely fast turnaround. If you want to optimize for that, you need to do some fixes in anticipation of need, and sometimes those will be wrong.

Rewrites should bring a lot of skepticism, and are often worse than turd polishing. If it's gotta happen people should be able to take that on evidence rather than respond because they've developed feelings for the turd.

[frollogaston]

I get that it's risky and expensive, but I haven't seen it work better than this. The hack workaround sometimes ends up being better than the existing system, cause a rushed timeline forces everyone to be frank about what's actually needed and what they can ignore. They're also forced to pick something simple, not design an overly grand solution with tons of meetings.

The tech debt is still costly, but most of it isn't caused by lack of maintenance, more that something was designed fundamentally poorly from the start.