If it ain’t broke, don’t fix it: Leave something alone; avoid attempting to correct, fix, or improve what is already sufficient (often with an implication that the attempted improvement is risky and might backfire). –Wiktionary
A lot of developers avoid improving the code they work on and if you ask them why, they’ll say, “If it ain’t broke, don’t fix it”. I understand their perspective: Every little refactoring could introduce a new bug and they “know” that the code works right now. Well, in my experience, when people have this attitude their project is usually broken in some way they just don’t know yet. But, that’s not the point of this article. The point of this article is that the, “if it ain’t broke, don’t fix it” attitude only makes sense on a finished product.
You can have the luxury of this attitude when it comes to your car, your TV, or your watch. When a watch is shipped, if a “version 2” comes out, it completely replaces “version 1”. Both “version 1” and “version 2” are finished, physical products that do not effect each other.
But, software is a different beast. Very rarely is software “finished”. Usually it is actively maintained for years and needs to be changed by a developer constantly. In this situation, you can’t have an “if it ain’t broke, don’t fix it” attitude because, working or not, it needs to change.