Re: code-sharing at work.

[blahblahblah]

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.

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.

[geekgrrl]

I totally agree that it is sometimes best to leave code alone. I've become much more "if it ain't broke" the longer I've been coding. I hate the idea of "starting from scratch." I know it is prone to failure and you have to refix all the bugs you spent hours fixing in the old version.

Of course, sometimes the code is just so clunky and horrendous, it needs refactoring NOW. I guess this would be the argument for maintainability.

But your method sounds pretty interesting - to add the new stuff, but leave the old alone. The dangerous thing is if someone else needs to update the code they have to update it in two different places or risk having different behaviors depending on which code they use. That of course depends a lot on communication, documentation and so forth. I guess I still am enough of a change-happy person to argue that the new code should replace the old as well.

rachel