Design Rule #002—Good Enough Isn’t Really Good Enough

Several years ago, one of my geek friends introduced me to the concept of “good enough” when designing software and hardware.

This friend’s creations are always interesting, innovative, and reliable. Some of her code is in devices I’d wager all of my friends and past colleagues have used often during their careers.

However, I neglected to press her for a detailed explanation, so was left with a distorted interpretation of what “good enough” meant. Frankly, I didn’t press the subject because I didn’t like the definition I thought she meant.

A few months ago, the concept became more important to me, and I finally asked her for the proper definition. And suddenly it all made sense, and meshed with my passion for quality and great interoperability, both bordering on perfection.

I believe most companies making products that don’t have the stock-ticker AAPL subscribe to the definition I had first imagined. Believing that “good enough” means the design is finished when it seems good enough to do the job, and be a bit better than the competition.

Every blue-screen of death should remind you of this definition. And every automotive recall that spans multiple years. I’m sure Ford wishes it could escape the lesson it learned this week. (Pun intended.)

Meh.

To excel on the level of that other company, you must be near-obsessive about all the details.

You have to get above the pain threshold in a combination of price, convenience, usability, and quality, as compared with the competition’s products.

Passing the right threshold in some combination will get you past the competition, for and by a bit, but won’t create a blockbuster.

In this case, “good enough” means that you keep researching, building, and testing until you have created something that makes you happy—something that you would buy at the proposed list price.

Reaching this higher threshold is much tougher, and requires giving a damn about the little details. The ones you will notice, and which will haunt you once the product ships if you don’t nail them.

With this in mind, I spent a lot of hours yesterday obsessing about a few different aspects of our product.

Yesterday morning was mostly spent researching protocols and APIs, searching for the right combination. I was fairly certain the combination was Good Enough (Apple’s definition) that it would be expedient for a while, until we come up with something better. The framework is a decent way to go and is architected and written in a way to make consistency and interoperability much easier than alternatives. Unfortunately, a related standards body has chosen to ignore this good design and is about to approve a big, ugly monster that I predict will fail to gain wide adoption, just as its predecessor did. Discovering this gave me a chance to reconsider my decision, but I realized that changing it to match someone else’s inside-the-box thinking would be detrimental to us.

The afternoon (and then some) was mostly devoted to researching connectors and what competitive systems have used. What we’re doing presently is standard practice and inexpensive, but also inelegant. This research consumed and engrossed me until 9:15 pm—a large number of hours spent looking for the right tiny 8ish pin connector—yet not out-of-line with the importance with the effects the decision will have down the road. Nothing I found was quite right. My top two choices are excellent, but only available in 4 and 6-pin versions, respectively.

This simple part will impact physical form factor, use scenarios, programming, and the ecosystem of third-party components. I’m convinced if we design this part of the system with Apple-like thinking, that it will help boost the warm-fuzzy feeling in our future customers enough to help us become the industry leader.

No, the choice of one connector alone will not cause that, but it will play a role, and this amount of care applied in the other areas combined will.

So even though I don’t have the complete connector answer yet, those hours were well-spent, and gave me a solid foundation with which to engage the right stakeholders and figure out the rest of the answer.

It would be so easy to just find something Close Enough (CEFHAHG—and I may yet take that route for the next intermediate version), but doing so would not be Good Enough for mass deployment, and this intermediate step might be the only opportunity to nail this. So the research will continue.

I spent a goodly number of hours yesterday and produced little visible work, yet I know it was one of my most productive days in the past few weeks because of the decisions on fundamental direction that are now forming as a result.

And if you happen to be playing around with programming gumball machines later today, you might divine from the questions I ask that that activity is somehow related to yesterday’s research and this post…