[conqrr]

This hits so hard. I used to admire Senior developers who would do this. Now, I find myself in a place where there is no one to do this, and I've taken up to playing this role. It is the hardest job, but I cannot do any thing else as my team is committed to just non-stop slop thanks to management directives. I realize all the time I spent admiring, and now I have become.

[repeekad]

If the engineers were right the bill will come due on that tech debt eventually. Likely when that happens the company will just spend more than they needed to fixing the issues and no one will be around to say I told you so.

[kentm]

The bill does come due. I've seen it happen over and over. But management fails to connect current problems to past mistakes, especially when they happen over the course of years. Thats setting aside when they insist that the correct decision was made, but have no real evidence that this is the case, other than the fact that "things worked out" even though maybe it would have been better had a different decision was made.

People do get a pass on this -- you can't rigorously examine every decision and counter-factual or you'd never make forward progress. And I don't really have any great ideas on how to bridge this gap. It'd be nice if there were better ways to measure this but there aren't, so it really comes down to who is more convincing, which is often orthogonal to facts and correctness.

[wk_end]

The problem is that the counterfactual isn't obvious. The company spends more time - and money - than they needed to fixing those issues, but how do they know? And how do they know that it would've amounted to less if they'd done those fixes sooner? Figuring that out, and figuring it out accurately, is often extremely difficult. A serious attempt might cost more than the fixes.

...and often the amount more isn't catastrophically more, so they don't even think about it. The company might be bleeding from paper cuts, it might be terribly unhealthy because of it, but still not unhealthy enough to kill it.

[SR2Z]

> Likely when that happens the company will just spend more than they needed to fixing the issues and no one will be around to say I told you so.

In my experience, yeah, but how they do it is... not what you'd expect.

Leadership has no clue about the scope of tech debt in their products and if they do decide to fix it, it will be by coming up with a bunch of ridiculously optimistic estimates and then foisting them off onto engineers who are already overworked trying to keep up with tech debt to launch new stuff. This feels awful and generally doesn't lead to anything being properly fixed because it turns fixing tech debt into a "just get it barely good enough and mark it as done."

After the inevitable surge in attrition, more often than not the tech debt is "solved" by throwing out the old codebase and starting from scratch with a new team. This is expensive, but in a lot of cases produces a better product.