I just read a post by Martin Rue who gets upset when people say “If it isn’t broken, don’t fix it.”
As it is being said, I detect the whatever works attitude emanating from the person saying it. No concept of continuous improvement. No interest in reflecting. Not even 60 seconds invested to consider whether the process is efficient or could be improved. It most cases it’s almost a canned response to any comment referring to the efficiency of a process that is considered to be working.
I have to say that I both agree and disagree with Martin on this one. Yes, there are many times when something can be improved or made more efficient, and people do not want to invest time and effort to transform the satisfactory to the exceptional. People should be striving for excellence, and it is depressing when they do not. Yet, I find myself taking this philosophy quite often, and here is why.
Sometimes, especially in the world of software, I find people want to spend a lot of time improving things underneath the hood. That’s well and good, but quite often this re-architecture makes no difference for the user. If a program is coded in an ugly and horrible way, but it’s fast and functional and optimal for the user, who cares? Unless you have a lot of extra free time, or the bad code is causing maintenance or performance issues, why should you fix it? You’ll basically just be spending time achieving effectively nothing if the user experience is identical. You’ll actually make it worse if you cause downtime or introduce new bugs, which is almost certain.
The other time you shouldn’t fix what isn’t broken is when you have something else to do. In every job I’ve had there have been multiple horrible computer systems to deal with. Almost none of them have been excellent, and many have been broken. Pretty much all of my time was spent fixing the broken ones. The other ones still sucked, and everybody knew it, but they worked. I guess I could sum it up by saying that you shouldn’t fix what isn’t broken if there’s something else that is in fact broken that you could be fixing.
Yeah, if everything works, and you can actually improve things for the user, go ahead and fix a non-broken system. Otherwise, the risk of causing some unnecessary downtime or introducing new bugs into a functional system is probably not worth whatever benefit your improvements might provide.
All this, of course, assumes you are in a business. If it’s open source or something, then strive for excellence no matter what.