I recently had a discussion about a proposed web architecture with a client who was making the request to “keep things simple.” I interpreted this as a plea to “keep things cheaper,” but played the Einstein-quote-card reassuring him that we will keep things “as simple as possible, but no simpler.” I’ve always liked this quote because it helps to ground everyone in the reality that design and engineering requires making ongoing tradeoff decisions until we get a product that works and makes sense for a long useful life. Tradeoff discussions are tricky, because the longer this discussion goes the more tradeoff concessions become visible. Then comes denial, anger, acceptance, and so on.
Thinking about this conversation later, I stumbled upon a great essay by Richard Gabriel, The Rise of Worse is Better. Originally a plea to the Lisp development community, it has become a classic piece, referencing a couple of what I would call all-purpose design rubrics.
The Right Thing (MIT/Stanford style)
- 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.
Worse-is-Better
- 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 be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.
I like these because they are, in and of themselves, simple. And in their simplicity they are useful in my next conversation about keeping things cheaper.
