Richard Gabriel’s Worse is Better (falsly attributed to jwz by many), is a piece on how LISP lost out to C, despite being ‘better’.

Jim Waldo’s Worse is Worse notes, quite accurately, that what us geeks consider ‘better’ might not what is, in the context of the universe at large, ‘better’. To quote,

[…] what we see is that better is a complicated notion, and can depend on a variety of different metrics. It may be disappointing to find out that what we geeks think of as better may not be what our customers think is better. But finding this out shouldn’t surprise us too much.

There is also explanations on how on many of the examples used to justify worse as being ‘better’, the wrong criteria was being used.

The original piece has been used to justify people producing shoddy, shitty work quite frequently. Waldo agrees:

My problem with the slogan is that it has become a catch phrase for those who either haven’t read the original article, or have read it and either have forgotten what it really talked about or never understood it in the first place. As a catch phrase, it is often used to justify shoddy design, or following the crowd rather than doing what is right, or as short-hand for the real claim that our customers are too stupid to either appreciate or deserve high quality products. Why spend the time doing things right, this line of reasoning goes, when we all know that worse is better. You are far better off giving the customer something that you know is less than what you could produce, because they (those simple customers) will think that it is better.

The end result of this thinking is sloppy products that don’t work, are hard to use, or are unreliable (or all of the above). We try to convince our customers that this is the way software has to be, and then turn around and convince ourselves that they won’t pay for anything better. But we short-change our customers, and we cheapen our craft, when we put up with this sort of thinking. When the original article was produced, I don’t think that this is what the author had in mind; even if it was, it is time for us to reject the simple-minded interpretation of the slogan, and start putting out software that really is better (on the dimension of goodness that our customers have, not necessarily our own).

I’ve sadly had to personally witness this at a few places. When ‘shit work’ becomes acceptable, it very soon becomes the norm. Eventually people consider that not just the norm, but something to aspire to – as if producing something that is actually shit is, somehow, better than producing something actually better. If you notice that happening to yourself / your project, please step back a bit, trout yourself, and do the right thing.