If you ask me, this is a pretty awful approach. "Bug-free", secure, and fast are not the only metrics of whether or not a codebase is worth keeping alive. Some

If you ask me, this is a pretty awful approach. "Bug-free", secure, and fast are not the only metrics of whether or not a codebase is worth keeping alive. Some codebases are so obscenely dangerous that you really shouldn't be giving a shit whether or not it "works", because it's only a matter of time before it doesn't. There are code practices that are inexcusable under any circumstance. Sitting on a fucking nailbomb when it's in your power to change it because you don't want the headache of having to push for a real solution will catch up with you in the end. I'm not saying that you have an option in a do-or-die situation where it needs to be done in a couple days. I'm also not saying that you should subvert or defy management to execute a massive overhaul or total rewrite. I am saying that if you understand a system, know that it's fundamentally flawed, and have a window to fix it (even if it's a really tiny one), but choose not to, you are part of the problem. The standards that software developers are held to in terms of quality are an absolute joke, and the "it hasn't completely imploded our business operation, so don't even think about fixing it" mentality is where those standards stem from.