Best is the Enemy of Good

Continuous Improvement
It was encouraging to me that my company decided to host a continuous improvement activity for the development group in our IT shop. If you've never done one of these before, it's related to process improvement and such things as LEAN and Six Sigma.

What I didn't understand before the activity was that LEAN is not about solving the root of the problem, it's about trying to streamline and make more efficient all the peripheral things in the total process. For example, in our workshop we identified that some of the production support load we get is from misdirected requests that should have gone to a different group. So we're taking steps to better educate users and other support personnel so they can reduce this source of inefficiency.

However, I asked about the fact that the real source of production support loads is often poorly built software, and it was accepted by the session consultant that indeed, LEAN does not always address the root problem. The example he used was from when he worked with a group that performed drilling on a designated area. Improved productivity could have been had by using a faster drill or technique, but that was not what LEAN was about. It was instead about all the particulars of the process leading to, during, and following the drilling, and removing wasteful elements in these phases of the total effort.

Another Adage
Anyway, improvement is good in any space, so I'll take what we get out of it even if it means the software we're using is still seriously flawed.

One of the interesting things emphasized during the workshop, however, was:

Don't let best be the enemy of good

This was meant to keep us from succumbing to paralysis by analysis. I've heard this same sentiment in another quote from Patton:

A good plan now is better than a great plan ten minutes from now

I can't disagree with the gist of those platitudes, but there is a fundamental problem facing most software teams that try to use that quote for enlightenment. What if the battle they're fighting isn't between good and best, but good and mediocre or poor? My version of the quote is therefore:

Best is the enemy of good, but don't confuse good with
mediocre

Remember: making software is easy, but making it right is hard! It is too easy to lower your standards and say "good enough." But as complicated as software is, the truth is that "good enough" is probably "bad enough" since corporate software is often poorly designed and poorly tested. Even if it is good enough, chances are you'll have to change it, and good enough can quickly become not-so-good.