Skip to content

Instantly share code, notes, and snippets.

@StevenACoffman
Last active March 25, 2026 12:37
Show Gist options
  • Select an option

  • Save StevenACoffman/62b1dbcff8537eb38341f44472e4a3f3 to your computer and use it in GitHub Desktop.

Select an option

Save StevenACoffman/62b1dbcff8537eb38341f44472e4a3f3 to your computer and use it in GitHub Desktop.
Worse-Is-Better

The New Jersey style (aka "Worse is Better") a model of software design and implementation which has the characteristics (in approximately descending order of importance):

  1. 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.

  2. Correctness: The design should be correct in all observable aspects. It is slightly better to be simple than correct.

  3. 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 complexity or inconsistency in the implementation.

  4. 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 be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

The MIT style:

  1. Simplicity: The design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.

  2. Correctness: The design must be correct in all observable aspects. Incorrectness is simply not allowed.

  3. Consistency: The design must be consistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.

  4. 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.

Addendum

Whenever possible, always err on the side of simplicity. Why use inheritance when a simple object will do? Why use inheritance when you can use an interface? Why even write code at all when you can buy or steal open-source it? In the spirit of Strunk and White, keep taking complexity away, and like words on a page, when you cannot remove any more – you're done.

Simple solutions survive and prosper because they work, and people can actually understand them. Don't presume that everyone's smart enough to handle the fancy complex solution; optimism is a dangerous occupational hazard for programmers. We should strive to build simple solutions whenever possible, even if we have to occasionally hold our noses when doing it.

Jeff Atwood

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment