Encyclopedia > Worse is better

  Article Content

Worse is better

Worse is better is the name of a computer software design style (or software design philosophy), also called the New Jersey approach. This design style was first clearly described by Richard P. Gabriel[?] in his essay, "The Rise of 'Worse is Better'", originally part of his work Lisp: Good News, Bad News, How to Win Big but often reprinted as a separate work.

Gabriel summarizes the "Worse is better" approach as an approach in which simplicity, of both interface and implementation, is more important than any other system attribute (including correctness, consistency, and completeness). More specifically, he characterizes "Worse is better" as emphasizing the following attributes:

  • Simplicity: the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
  • Correctness: the design must be correct in all observable aspects. It is slightly better to be simple than correct.
  • Consistency: the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
  • Completeness: the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

He argues that early Unix and C are examples of this design approach.

Gabriel contrasts this philosophy to the so-called "MIT approach", which he describes as follows:

  • Simplicity: the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.
  • Correctness: the design must be correct in all observable aspects. Incorrectness is simply not allowed.
  • Consistency: the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.
  • Completeness: the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.

Gabriel argues that "Worse is better" is generally superior to the "MIT approach". As long as the initial program is basically good, it is easier to port to new machines and situations, and will take much less time and effort to implement initially. Thus, its use will spread rapidly, long before a program developed using the "MIT approach" has a chance to be developed and deployed. Once it has spread, there will be pressure to improve it by improving its functionality, but users have already been conditioned to accept worse than the "right thing". "Therefore, the 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. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better."

References

Lisp: Good News, Bad News, How to Win Big (http://www.ai.mit.edu/docs/articles/good-news/good-news), Richard P. Gabriel.



All Wikipedia text is available under the terms of the GNU Free Documentation License

 
  Search Encyclopedia

Search over one million articles, find something about almost anything!
 
 
  
  Featured Article
Grateful Dead

... Mickey played drums, and a wide variety of other percussion instruments. Following Pigpen's death, several people played keyboards. In 1973, Keith Godchaux[?] followed ...

 
 
 
This page was created in 115.3 ms