>That' exactly that I heard lots ot times. "If it's not broken, don't fix it." Still my sense of coding style and efficiency of the code moves me to the changing and enhancing. Sometimes it's really hard to "keep" myself and don't change it. For my own projects I do it all the time, but when I tried to do it with my colleagues code, I usually got some unpleasant remarks and people became offensive. Well, I know, I have to shout my mouth and don't point to obvious flaws, holes or unefficient code, but sometimes I just can't...
>

As someone whose carear has been over 75% legacy maintenance (by choice I would add - I'm the odd duck that actually enjoys fixing and enhancing rather than building), I would say IF IT AIN'T BROKE, DON'T FIX IT . The worse the original code, the more this statement is true.

The main reason is the "Law of Unintended Consequences." Fixing this one little flaw here will ripple through a poorly designed system and cause breakdowns somewhere else. Maintenance programmers seldom have a chance to perform a full system test for each little fix. Because what we work on usually needs immediate attention we tend to unit test, install, and pray nothing breaks further down the road. My groups supports an old system which has expanded, been patched up, and kludged so many times it looks like abstract art. The "as long as I'm here I might as well clean up this other stuff as well" syndrome has caused us hours of additional maintenance - all so that we could shave 2 seconds from a five minute process.

A secondary reason is that mixing programming styles in the same program makes the code more difficult to understand ("I wonder why they did it THAT way there but THIS way here") to the person who picks it up when you are done. (I know I react that way - I'm not sure about anybody else)

Another problem, as you've discovered, is the ego attack felt by the person whose code is modified. Your skills and abilities are much appreciated here by those of us who learn from your posts (and I'm glad to be part of that group). Your co-workers, however, could easily perceive them as threatening since they will be expected to bring their productivity level up to yours.

So, while I'm not in favor of inefficient code (despite what looking at my programs would indicate < g >) my opinion is If it ain't broke, don't fix it.