Hacker News new | past | comments | ask | show | jobs | submit login
The "if it isn't broken, don't fix it" Mentality (invalidcast.com)
29 points by martinrue on June 18, 2010 | hide | past | favorite | 19 comments



Article completely misses the actual point of the old "If it ain't broke, don't fix it" maxim: if you try to fix it, you might screw it up.

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 agree. About a year ago we hired a new person at work and he immediately started looking for ways to improve anything and everything. The problem is, nearly everything we had that wasn't optimal, was still actually "good enough" for our needs and usually included some complexity that wasn't obvious at first glance. He ignored our "if it's not broken, don't fix it" advice and every single time he tried to improve something he ended up breaking it or making it worse.

Sometimes a simple but sub-optimal solution that gets the job done well enough and reliably is better than an optimized solution that includes downtime and requires extra maintenance. I don't think the person offering the advice to leave things alone is always the naïve one.


If you back your case against change with real arguments (like “There will be massive downtime.” and “Extra maintenance will be necessary.”) you certainly aren’t naïve. But you are very naïve indeed if all you ever say to anyone proposing any change to working systems is “If it ain’t broke, don’t fix it!”


Agreed. In reality, there's a balance to be made between the cost of maintaining the status quo (in the event that the status quo sucks) and the cost of making changes.

One thing that really frustrated me when I started my career is that the cost of making changes turns out to be non-trivial. If you're shipping software to customers then making changes to the software involves a lot of work planning testing, packaging and so on. Maybe that's one of the reasons why hosting web apps is so much easier than selling shrink-wrapped software in a box.


This is true sometimes. Other times it is used because fixing the problem exposes far larger systematic flaws that relied on the bug, changing a simple fix into a massive refactoring project.

I think the position you put forward however is often a mask for fear. People don't like change, particularly when they don't understand what is going on already. It is a sunk-cost fallacy. They invested a bunch of effort in learning the old way, which they didn't fully understand, but apparently it worked, so the accepted it. Now a new way comes along, claiming to be better, but once again, they don't understand it fully, so they just see it as an attack on the way they had been doing stuff -- which in a lot of people's minds translates to an attack on them. When this happens they start justifying "It was fine the old way, I don't see why they had to change it.". Those with some foresight then start saying "if it ain't broken don't fix it" when a change is coming down the pipe. This causes people who can see the benefit of the change to write articles like the one we're commenting on.


That doesn’t make the phrase useful. It’s a catch-all phrase, often dropped without any arguments backing it up, vilifying any change to any working system.

There are good reasons why you sometimes really shouldn’t change working systems (you mentioned one), but then you shouldn’t use that phrase and leave it at that. Say something like “Changing the system in the proposed way at this time would be bad because of reasons A, B and C.” or something similar. Don’t take “If it ain’t broke, don’t fix it!” as a self-evident truth.


I'm trying to emphasise the focus on quality in the article. If you're fearful of breaking it this is not good. We need to be confident that we can make changes without screwing it up.

Too many people create poor first attempts and leave it at that (the example I used was a process which breaks once per month, indicating there is room for improvement that would save Fred time), claiming later "if it ain't broke". I think this is a recipe for disaster because it reflects an attitude that lacks a desire to improve.

However, there are times when it "ain't broken" and it is good enough, and in those situations I agree with other comments that you wouldn't want people wasting time looking to make micro-optimisations. Ultimately I am making the point that people need to have the right attitude toward improvement and quality overall.


It comes down to where you apply the phrase. In my experience, back-end under-the-hood type stuff is either broken, has to be done manually, or works automatically. So long as performance is not an issue, once you've reached automagicality, there's no reason to fix it until it breaks!

Front-end and performance type things benefit more from continual improvement, and "If it ain't broke, don't fix it" isn't as useful.


While I agree that the usage you describe is the original meaning of the phrase, I find that there are many people who use it as the article describes. It becomes an excuse for mediocrity.

Does it take some extra effort to reflect on a process and figure out ways to improve it? Of course it does, and that's ok. I take pride in my work, and I like to be surrounded by others that do too. I would rather have to put in that extra effort in an attempt to make something really great, than to go through life leaving a trail of mediocrity in my wake.


That's why I prefer the "If it ain't broke, don't break it" locution.


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.

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.

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.


There is actually studies that one bad guy on a team makes the overall team good

Can you cite one? This would be very counterintuitive if true.

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.

That would imply either that they are contributing something or that their replacement is even worse. If they are contributing something, identifying what so it can be focused on and improved is of great value in a highly competitive arena. If the replacement is even worse, then a better replacement should be found.

So, sometimes the maxim is good when you can't pinpoint where your victory is coming from.

In cases like that, there is often great value in spending the time and thought to figure out. To Quote Sun Tzu, "If you do not know your enemies nor yourself, you will be imperiled in every single battle"


I can't find the exact paper that cites it(Anyone who have heard of this plz chime in). But, I can cite you apollo syndrome which basically is putting the best and the brightest on a team with the assumption they will do well. http://www2.warwick.ac.uk/fac/med/research/hsri/emergencycar...

Also, other example of where if it ain't broken don't fix it is Founder CEO. Founder CEO tend to perform better than Professional CEO even though they have less experience and knowledge. http://opim.wharton.upenn.edu/enabletech/2010/04/28/ugc-foun...

Somethings are counter-intuitive. Although it is possible with some research to get to heart of things, doing so might be prohibitive in terms of cost and time.


Founder CEO tend to perform better than Professional CEO even though they have less experience and knowledge.

That is a very different situation. Founder/CEO's often have 2 major advantages over Professional CEOs. The first is that the Founder is more motivated. The second is that the Founder often knows their field very well, whereas professional CEOs are often leadership experts holding MBAs. Especially in the early stages, knowing the field and being able to do much of the work personally can be more valuable than the skills that an MBA business expert brings to bear.


But still there is a need by some VC to optimize this.

In Ben Horowitz blog he says:

"When my partner Marc wrote his post describing our firm, the most controversial component of our investment strategy was our preference for founding CEOs. The conventional wisdom says a startup CEO should make way for a professional CEO once the company has achieved product-market fit. In this post, I describe why we prefer to fund companies whose founder will run the company as its CEO."

http://bhorowitz.com/2010/04/28/why-we-prefer-founding-ceos/ Dated: 04/28/10

To you and me this is clear cut but for some VC the wisdom would say to get a Professional. The first thing that came to my mind when I read it was why change a good thing?

I didn't have any data for backing keeping the founding CEO but without data I think the maxim serves as a good heuristic.


You adopt two attitudes towards "if it ain't broke, don't fix it" in two similar ways:

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.

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.

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:

http://en.wikipedia.org/wiki/Kaizen


Yes, the problem is that fixing stuff can (and does) create regressions.

So what REALLY HELPS is -- Fix ONE thing at a time.

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.

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".

It is too subjective.

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!




Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: