Change

Whoever said that change is good probably wasn't a programmer.

I don't know about you, but if my code is running well and isn't eating up too many system resources, I don't want to change it. This is particularly true for purely stylistic changes. For example, I am seeing a lot of code like this in a program I've been reviewing:

if(a == false){    Do action;}

if(b == true){    Do action;}

This syntax isn't going to throw any errors, but it bothers me because it's not good idiomatic C++. A better (and equivalent) way to express these statements would be:

if(!a){    Do action;}

if(b){    Do action;}

If this was a novel -- or even one of my students' papers -- I would slash away with my red pen. With production code, however, that can be dangerous.

Yes, cleaning up legacy code can improve readability and, in some cases, even performance. But the risk of bumping or forgetting something in the process is greater than any benefit I can imagine from making the change.

Bottom line: in written or spoken English, I am quick to assert my preferences. The risk is low and I have the experience to back my preferences up. In production code, though, my motto is closer to "If it ain't broke, don't fix it."