I stumbled across this excellent commentary from Stephen Baker in BusinessWeek on "good enough" technology. It's actually a great foil to an earlier post I wrote on software as a service (SaaS).
Baker asks, "Are we helped or hindered by imperfect technology that is merely 'good enough'?" He comes down squarely on the "helped" side, and with interesting reasons:
We're surrounded by miraculous machines and services, most of them calibrated to a level software engineers have long called "good enough." In the right circumstances, good enough is great for the entire economy. A marketplace that's not hung up on fail-safe standards is open to risk and innovation, and drives down prices. Ever since the dawn of the PC--the archetype for a good-enough machine--inventors have been freer than ever to piece together and launch their visions. Some are brilliant, some are half-baked, many are a blend of the two. A precious few are up and running 99.999 percent of the time--Bell's old standard. But they cost far less to build.
The rise of good-enough technology raises different questions for do-it-yourselfers and major corporations alike. It's no longer whether we can afford a technology, but more often whether we can afford the disruption if and when it fails. Is it critical? Do we have backup in place? Many of us face this question every time we venture from our office with a cell phone. We don't have "one machine that works all the time," says Dave Morgan, chairman of Tacoda Inc., a New York advertising company. "We have lots of alternatives that work most of the time."
"Good enough" frees up time and resources to experiment with new approaches to technology, rather than fixating on perfecting old approaches. For example, I've long criticized Google for spitting out so many half-baked projects that never approach relevance.
But perhaps that's the point. "Good enough" is just that: good enough for some people for some things and likely not good enough for others. The things that work, work. The things that don't...reside in eternal beta.
Software as a service is scary on some fronts (security, uptime, etc.), but maybe for the price, who cares? Speaking more broadly, should IT be focused on the holy grail of uptime and availability, or good enough uptime at a killer price? Because once we stop worshiping uptime, all sorts of great alternatives reveal themselves that are innovative and cheap.
As Baker points out, we've abandoned reliability in our phone service for convenience and cost. I use Vonage because I have to make a lot of international calls. The service is mostly good, but at least once per week (and often once per day) my phone will cut out in the middle of a call. Yet I stay with it. Why? Because I can call my colleagues in the U.K. for free, and my parents in Argentina for pennies per minute. The 99.999 percent uptime I could get with AT&T isn't worth the price tag for me.
On the IT side, Baker poses a hugely important question: Is good enough good enough? If so (and, frankly, it should be for most every application), then our options expand dramatically as to how we resolve our needs. If not, we're likely going to be forced into a system that requires that we live by its rules, rather than having innovative software that adapts to ours.
That's the trade-off. Innovation and cost for "perfection." Suddenly, "good enough" never sounded so good.