Sometimes "if it ain't broke don't fix it" is a valid attitude. Don't get me wrong: usually my first instinct is to rewrite bad code that I come across. But I've learned that there are good reasons for checking that instinct. You have to weigh the risk of breaking existing behavior (which is greater when you have poor documentation and no test code) and the amount time you're spending (which others might view as wasted time) against the benefits of the change.
in reply to code-sharing at work.
The happy medium that I've found is to write new subs which I use in all future code, while leaving the old code alone. To use your database example, I would start by writing a great new connection sub, and then I would use it in all of my future code that needs to connect to the db. If the new sub isn't functionaly much better than the other old code, maybe I'll leave it at that. (I'll still be happier because in my eyes the code is better organized and easier to maintain, but I don't have much of an argument for spending any time rewriting the old code.) Maybe I'll eventually add better error reporting, retries after failed connection attempts, logging, and other improvements to the sub. At that point I'll have a good argument for getting my coworkers to use the sub, and maybe even a justification for spending the time to retro-fit it into the old code.