Sunday, August 30, 2009

Worse is better

I was reading yesterday about Richard P. Gabriel's classic worse-is-better theory, which wraps a lot of related concepts, such as less is more, good enough is good enough, KISS, and YAGNI. The key intuition is that the more you try to perfect something by adding to it, the less perfect it gets -- so don't try to perfect it. Leave it imperfect, it'll be better that way. Worse is better.

Alas, worse-is-better goes against more entrenched philosophies like "correctness before efficiency" and "completeness over simplicity."

On a business level, it goes against the philosophy of give-the-customer-every-damn-feature-he-wants. It says let's leave a large number of ultimately unimportant features out, and concentrate on making the rest do what it's supposed to do.

A prototype or proof-of-concept that slam-dunks the desired functionality, but sucks at the code level because classes aren't cleanly factored, is an example of worse-is-better. Chances are, when the POC is later discarded, then reimplemented "correctly" by a team of GoF acolytes, it will morph into an overfactored, underperforming pig with unexplainable memory leaks and a hard-to-describe odor. (But hey, it'll scale.)

Is worse always better? Of course not. Better is, by and large, better. Just not in the software world, where "better" tends to take on unexpected meanings.


  1. A man to my own mind. I adapted the slogan "Progress Before Perfection" about six months ago.

  2. You shouldn't forget though that this only applies to "better" as defined by "more functionality." Not to "better" as defined as "the same thing, but actually working."

    That's the problem with many PoCs -- they don't really work (...if only because they don't scale.) Actually building that functionality, but getting it to work is usually a painful experience (especially if you start by using the "working" code from the PoC.) I think the problem with a lot of PoCs is "but we already had it working, didn't we, so why are we spending time on this?"

    Likewise, I think "Progress Before Perfection" is a very dangerous slogan (sorry Brady.) Perfecting existing functionality to actually work is usually not seen as progress. Adding functionality, however, ís seen as tangible progress, even if nobody takes the time to make it work...

    So if you boil it all down, "worse is better" means "less functionality (but working) is better than more functionality (which doesn't work or isn't needed)." If you translate that, you end up with "less is more," but we already had that paradigm, so why not stick with it? :P


Add a comment. Registration required because trolls.