I've seen code so bad that it was declared to be a total loss after the original programmer was discharged.
One time, the company split into two: One skeleton crew to maintain the "bad" code in production, and everyone else was allocated to the rewrite.
I was able to refactor and improve the "bad" code without much trouble. I'm pretty sure the reason it was deemed so bad was because certain engineers didn't actually try to work with it. They got offended by it quickly and gave up.
The rewrite failed btw - when I left, they were about to rewrite the rewrite (they had recently hired a new CTO).
The "bad" code brought in millions of dollars. It might still be doing so lol.
I was pretty junior in my career when this happened. It taught me that most senior engineers are posers. That generalization has only been reinforced as I've gotten more experience.
My employer is doing this now. I'm on the maintenance side. I am not refactoring it quietly, yet. I am quietly supporting the rewrite team, although I won't get credit for it.
The 'bad' code makes us money today. The new code costs us money today. I doubt it will ever be better enough to pay for its own development. But that does not seem to matter. Mgmt wants to be like google. Mgmt wants a bigger org.
Not much I can do except to keep the money coming in today.
Started on the rewrite, noticed it wasn't gonna go anywhere, asked to switch to maintaining the money maker.
Didn't need to refactor much: the code quality was VASTLY superior than the new system. However I not-so-silently worked on a redesign.
After four years not working there, the old system is still running full steam. The new one was shelved.
As others have pointed out, just like in software, we have to be cognizant of the career risk of hitching one's wagon to the product that's going out the door.