The authors of the Pragmatic Programmer (great book btw, highly recommended) have a lot of insights into the craft of software development, but in my opinion one of the most powerful ideas is that "living with broken windows" drives quality downward in a depressing spiral of entropy.  Well, they put it a lot more eloquently than that, but the idea is that when you're working in a codebase that's littered with problems, bugs, sloppiness, etc, you and your team are much more likely to do sloppy work.  Your standards are lowered by the sheer weight of the code around you, in spite of your best intentions and even explicit attempts to do high-quality work.  This is a great argument for continued refactoring of existing code, even if that code is more or less functional.  It can affect the quality of new code just by its presence in the same codebase.  It's like a poison, or at least a bad smelling swamp gas...

I won't attempt to elaborate much more on the concept - this article explains it much better than I'm likely to.  Go ahead and use up some of your daily or weekly geek reading time on that article - it's time well spent.

What's your experience like?  Have trouble keeping high standards when working on crappy legacy code that someone-who's-no-longer-working-here-for-a-good-reason wrote?  Wish you could rewrite that whole module or function from scratch but just don't think you have the time?  Can't convince your Dev or Product manager to let you have the time to refactor that painful and buggy sub-system?  Or, have you been able to clean up parts of your codebase with positive results? Was it worth it? Do you think it really makes much of a difference?  Or, can you manage to keep your work up to all the awesome standards that you have in spite of the muck that you're wading around in?

What do YOU think?

P.S. Don't take this as suggesting that all of the legacy code is crap - it's not.  There's a lot of really great code out there, I know.  And you don't need to look only at 'legacy' code to find sloppiness either.  These are big generalizations, but I think they're useful ones that apply to much more than just code.