Subscribe! It's free.

Join >690 folks who use these tools and ideas (everything here requires registration; it’s your call if you want a newsletter about it).

Subscribe
  • Home
  • Worse Is Better
By Clay Parker Jones profile image Clay Parker Jones
1 min read

Worse Is Better

I was familiar with “Weniger aber besser”. But until I started diving into Linux vs. Unix (as a result of my week in Vegas) I’d never heard of “Worse is Better.” It’s a concept in software engineering that indicates an inverse relationship between quality and functionality (more functionality

I was familiar with “Weniger aber besser”. But until I started diving into Linux vs. Unix (as a result of my week in Vegas) I’d never heard of “Worse is Better.” It’s a concept in software engineering that indicates an inverse relationship between quality and functionality (more functionality = less quality), particularly because additional complexity makes software harder to adopt and use. “Worse is Better” (WIB) comes from an essay circa 1990 by Richard Gabriel, contrasting the “MIT/Stanford” approach to WIB:

MIT/Stanford:

  1. The design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.
  2. The design must be correct in all observable aspects. Incorrectness is simply not allowed.
  3. 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.
  4. 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.

Worse-is-Better:

  1. 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.
  2. The design must be correct in all observable aspects. It is slightly better to be simple than correct.
  3. 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.
  4. 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.

The basic premise is that a simpler system will be easier to implement. It won’t be perfect, but because it’s easier to implement, it’ll get implemented by more people. And all those people will shoulder the hard work of making it perfect.

By Clay Parker Jones profile image Clay Parker Jones
Updated on