cLabs

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

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.

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.

Good enough, for those that seek perfection, is what we call it when it's sufficient to surpass the standards we've set. Anything beyond good enough is called stalling and a waste of time.

If you don't like your definition of ‘good enough’, then feel free to change that, but the goal before shipping is merely that. Not perfect.

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.

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.