The "if it isn't broken, don't fix it" Mentality

Article completely misses the actual <i>point</i> of the old "If it ain't broke, don't fix it" maxim: <i>if you try to fix it, you might screw it up</i>.<p>When you hear people saying "if it ain't broke..." it means they're concerned about accidentally making matters worse, not that they're lazy or insufficiently concerned with "continuous improvement".

I think the phrase comes in handy when the way to improve something is not so linear. For example selecction of team members on a startup.<p>Your startup is doing well but one guy aint pulling his weight. Do you sack him? There is actually studies that one bad guy on a team makes the overall team good.<p>Also, there was some stuff on here about basketball players who don't seem contribute anything but the team winning rate decreases when they aren't there. So, sometimes the maxim is good when you can't pinpoint where your victory is coming from.

You adopt two attitudes towards "if it ain't broke, don't fix it" in two similar ways:<p>1) Don't try to fix it or you might break it! 2) If it ain't broke then you can still try to improve it.<p>The reality is that there is a balancing act between the two. On the one hand, a process or system might be so delicate that any attempt to improve it will be difficult and dangerous.<p>On the other hand is the attitude that the author of the article takes: it's dangerous to become satisfied with the current state of affairs just because it's difficult to make changes. I like the fact that he mentions Toyota. The concept of continuous improvement immediately makes me think of Japanese companies and I'm sure we can think of many that became very successful by employing the following ideas:<p><a href="http://en.wikipedia.org/wiki/Kaizen" rel="nofollow">http://en.wikipedia.org/wiki/Kaizen</a>

Yes, the problem is that fixing stuff can (and does) create regressions.<p>So what REALLY HELPS is -- Fix ONE thing at a time.<p>Usually, when I'm writing code or fixing something, I put in a couple of unrelated improvements. There's a pretty good chance the unrelated improvements will break something.<p>Breaking the unrelated improvements into their own separate self-contained step is usually all it takes.

The biggest problem I've had with this maxim in the past is the definition of "Broke".<p>It is too subjective.<p>There is a world of difference between "a bit broke" and "totally broke" even for the simplest of systems.

even if it isn't fixed, don't break it!