01 July 2009

Worse Is Better

I'm a self-described "imperfectionist," much preferring an imperfect-but-feasible approach over a perfect-but-unobtainable one. This preference covers technology design and organizational structures, as well as processes, etc. In practice, imperfectionism is a preference for simplicity over complexity and adequacy over completeness.

A while back, I came across a little paper by Richard Gabriel, titled The Rise of "Worse is Better." The context of this paper is software (Lisp specifically), but I think it applies to all sorts of design work. Gabriel's philosophy is very much in line with my own imperfectionism, and his paper offers the following insights, which I offer for your consideration:

Simplicity is the most important consideration in design.

It is slightly better to be simple than correct.

...it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementation complexity or inconsistency.

Completeness can be sacrified in favor of any other quality. In fact, completeness must be sacrified whenever implementation simplicity is jeopardized.

The worse-is-better philosophy means that implementation simplicity has highest priority...

... worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing.

... it is often undesirable to go for the right thing first. It is better to get half ofthe right thing available so that is spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.

Any reaction to these ideas?

4 comments:

Andrew Meyer said...

Dan,

I think we've faced some of the same problems, though you use some different terms.

What about the idea of: "Our first step has to be good enough." There was an military rule of thumb that I remember that went something like 80% of the cost is to deliver the last 20% of performance. That's probably pretty close to true.

The kicker is that that 80% of cost is also time and effort. It is better to get something out in 2 months that makes people's lives better, than to leave them struggling for 10 months with nothing.

PHP is the perfect example of this. For all it's short comings, lack of elegance and problems, it literally holds the internet together. Python is immensely more elegant and potentially powerful, but PHP is good enough and you can train someone and make them productive in a day. If someone makes a mistake, it only effects one page, not the whole program and you can find programmers by the millions and pay them $20/hr to be productive. For most things one needs to do, it's 'good enough'.

The other great thing about 'good enough' releases, users actually use the tool, provide feedback and their feedback is reflected in the product. Do something 100% complete and it's very hard to incorporate suggestions.

It's really the suggestions that make 'good enough' better.

Andy 'OK' Meyer

Gabe said...

Andy, the part about PHP you mention gave me an epiphany. If you have an org where people can accomplish "management-beureucratic-paperwork" stuff easily, wouldn't that also make them more productive? So this idea applies across disciplines.

Unknown said...

Brilliant, Andy! "The suggestions make good enough better" - I think that nails it!

Don C said...

I think there's a real need for discernment about constitutes "good enough". Does the designer get to judge that? Or is it the person who has to use it?

Also, I think good enough is most effective when in dialog with execellence. http://sethgodin.typepad.com/seths_blog/2009/06/on-the-road-to-mediocrity.html. How do we prevent "good enough" from taking over completely?