//BusinessWorld/
TheInevitabilityOfGoodEnough


Seth wrote:
...here are my two big ideas to start:

1. Humans tend to work on a problem until they get a good enough solution, instead of a solution that's right.

2. The marketplace often rewards solutions that are cheaper and good enough, instead of investing in the solution that promises to lead to the right answer.

I emailed him back:
Isn't good enough inevitable? Doesn't the square drive screw have some deficiency to it? Perhaps there's a better way to attach things together than any sort of screw could provide. Maybe we're not investing enough time in making duct tape better.

Better always is going to take some effort, and effort is not limitless. I can't go everywhere at once on a journey, I can only do one step, right now, one direction.

Your big ideas make a big assumption: that we can know ahead of time what the right answer is. Sometimes we can, but many times better only becomes visible once we've arrived at good enough.

Seth's follow-up puts a good bit of weight on the other end of the issue:
I'm not arguing that nothing is good enough. Far from it. ... But for those that are intent on creating something remarkable, it seems that the attractive vision is to believe precisely the opposite, at least about the stuff you care about.



JonathanKohl emailed me some linkage to two articles by JamesBach on this topic. In the first, James makes this point:
Good Enough has nothing to do with mediocrity. It has to do with rational choices, as opposed to compulsive behavior. ... CemKaner, in Testing Computer Software (International Thomson Press, 1993)—standard issue to Microsoft's testers—also refers to bug fix deferral as a routine practice.

Jonathan added this bit about corporate denial in his email...
In my experience, projects that have unrealistic goals of perfection (zero defects comes to mind) tend to fail. The zero defect goal on a project always leads to politicizing failure-reporting and redefining terms. "That's not a 'defect', that's an 'issue'" is a very common one. Quality suffers because people are measured by impossible goals, so the truth gets hidden. Here's an example I saw on an Agile project that had unrealistic goals: testers and customers were bullied into not logging defects, developers redefined defects as only something that occurred after shipping the product, and even then wouldn't acknowledge problems because only one or two customers reported it.
... and then liked the topic so much, he blogged it himself.

see also ConstructionAnalogy
email
subscribe

rss

cLabs

cuber mer

blogs i read



comment

| Email | Reload ? || Find | Recent | Home last update: Fri Aug 19 2005 06:28 PM