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.

In the end, this attitude is just wishful thinking. The reality is

you have to change software all the time anyway, so you may as well invest in improvements. Write some tests, refactor some code, etc. You’re going to be working on it for a while, so you may as well make your life easier while you do.

Besides, with software there is wiggle room for the definition of “broken”. For example, if I have to deploy an application 3 times a day and it takes 20-30 minutes to deploy each time, I consider that “broken”. It doesn’t matter that a customer can’t tell the difference, it’s worth improving this situation. Henry Ford used assembly lines in his factories even though the customer couldn’t tell the difference. You should follow suit and streamline your processes.

One last note: If there is software or siloed features at your company that aren’t actively maintained, that’s a “finished” state. In that situation I agree: If it ain’t broke, don’t fix it. But, this article isn’t about that situation. It’s about developers who use this attitude to avoid improving all software they work on.