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".
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.
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.
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.
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.
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.
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.
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.
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.
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"
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.
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.
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.
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."
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.
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:
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.
It is too subjective.
There is a world of difference between "a bit broke" and "totally broke" even for the simplest of systems.