Well, this is where we get "The programmer who previously worked on your code is always an idiot." Theorem.

There's really no way around this, as to most businesses see things on a very different plane than coders.
We're taught to see the bad, change, make better, even add features, etc. from our natural tendencies as programmers (I rarely meet coders who do not love a good challenge and like to help out.)
To a business, however, a program is a program. To them, if it works, if it's stable, if it does what it needs to do, that's good enough, and revision would almost be a sin.
If you stand back and look at it from their perspective, it's a bit like OO programming to us. We see an object, we know that if we put in X file and send it through X processes, we're returned what we expect. The inner details can be completely invisible.

For all of us who ever took apart a broken TV only to find there *really are* no serviceable parts inside, or tried to reassemble an old pocket-watch, there's this "let me fix it, let me make it better" feeling. Especially if it makes our jobs easier in the future.

Those who aren't 'in the know' often can't/won't see the utility of changing code that works. To them, code quality might be intangible.

If you can show them on a level that matters to them, value in dollars/manhours of maintaining bad code vs. time to rewrite, you may get your shot. But if the numbers don't add up, well, enjoy wading through that code through the rest of your tenure.


Jaded? Heh heh, kinda.
cidaris