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.
“if it’s not broken, fix it until it is”, is one possible reply.
Thanks for taking the time to write a reply, I’m pleased these kinds of discussions are appearing as I think it’s an important subject.
I agree with the general theme of your reply, which seems to be that sometimes you have more important things to do while other times you may be creating micro-optimisations that don’t have a sufficient ROI. I agree with both points.
In my article I wanted to provoke the idea of an attitude that considers these things. What I get upset about is when people use the phrase “if it ain’t broken” as a canned response without bothering to think of any of the things you mention.
In reality, perhaps when they do expend a little of their grey matter they might find that the process is “good enough” and wouldn’t provide *enough* of an increase (if any) business value, in which case it makes no sense to spend the time that could be better spent elsewhere (as you point out).
But essentially, striving for excellence while being pragmatic towards business (after all, we do this for the customer) is the attitude I was hoping to demonstrate.
I had one final thought regarding your commentary, too:
“If a program is coded in an ugly and horrible way, but it’s fast and functional and optimal for the user, who cares?”
In this case, you may be right, but it could certainly depend on the variability of this system. If its implementation is ugly and horrible but it’s something that is *very unlikely* to change, the ROI is going to be low, sure. However, if this system has a high expected variability then making sure the system is easy to change (which it may not be the case of the ugly and horrible version) might save many hours down the line – I’ve seen this theme in systems often.
So with that, thanks for the reply and generally I agree. My point was a little deeper in that I want people to think about these issues and be responsible, rather than rummaging through the canned response bucket for a way to excuse themselves from being responsible and using their brain.