[Silhouette]

Allowing technical debt to accumulate like that will, with near 100% certainty, damage your development activity sooner or later. The only exception is if you've already damaged it critically in some other way.

Some contrived example where you might lose significant money because you made a generally good change but it had a bug and that bug was somehow missed by your entire review and testing process and the consequence of that bug was able to go unnoticed for a long time in production and then the result was disastrous isn't really a very compelling counter-argument.

If you subsequently hold weeks of post-mortems, meetings, process improvements and outright terminations, the person who made the otherwise useful change that had a bug should be among the last to get called out, somewhere after the entire management chain who utterly failed to competently organise critical development and operations activities, everyone responsible for QA who couldn't spot such a critical problem early, and everyone involved in the data science who ran such a hazardous experiment without taking better precautions around validity.

[foobarian]

Well. It's not a counter-argument to anything, it's an illustration of how we end up with bad codebases, and why specifically in big enterprises. The incentives are set up exactly in the way that lead to it, particularly by making it expensive to clean up tech debt.

[Silhouette]

Fair enough if that was the point you wanted to make, though in that case I'd argue that the kind of disaster scenario you described isn't specific to big enterprises but to disastrously bad software development organisations. A lot of small organisations think they're operating at enterprise scale and make the same kinds of mistakes!