> You have an amazing amount of confidence that the new devs are going to fix subtle race conditions…
> They’ll add a few sleep(5) calls to make them go away though..
I don't think torginus's point is that the new devs will find the proper fixes for the code, more that such a hack might be good enough in the eyes of both the company's management and the company's users.
As much as it pains me to recognize this (as a fan of clean, elegant code) not every bit of software needs to be clean and elegant to achieve its intended purpose (which is, at least in the corporate software world being discussed here, to make money).
If you meet the needs of your software's users, you can make a lot of money for a lot of years selling a piece of crap held together with chewing gum and elastic bands (and many companies have).
Such "sleep(5)" is actually a milestone in a project, a milestone that marks the beginning of deterioration and the end of architectural changes. I've seen multiple pull requests with "sleep" and similar shortcuts, and worse, I've rewound coding agent context and changes because of such model suggestions. I'm responsible for informing management about the consequences of such shortcuts and why we have to take the correct, often more time-consuming and more expensive, approach to avoid project derailment in the long term. I believe that management picks employees. If they don't trust my judgment, then it's okay for me, but I don't feel obliged to be responsible for the consequences.
I'm certainly not defending such code, just saying that its out there and in some very successful projects.
If the managers where you work understand the dangers of taking on such tech debt and are willing to put in the resources to avoid it, consider yourself lucky, because in my experience that's not at all universal, or even particularly common, though it does certainly exist at some places.
> They’ll add a few sleep(5) calls to make them go away though..
I don't think torginus's point is that the new devs will find the proper fixes for the code, more that such a hack might be good enough in the eyes of both the company's management and the company's users.
As much as it pains me to recognize this (as a fan of clean, elegant code) not every bit of software needs to be clean and elegant to achieve its intended purpose (which is, at least in the corporate software world being discussed here, to make money).
If you meet the needs of your software's users, you can make a lot of money for a lot of years selling a piece of crap held together with chewing gum and elastic bands (and many companies have).