The Artima Developer Community
Sponsored Link

Weblogs Forum
Worse is worse

34 replies on 3 pages. Most recent reply: Jan 17, 2009 9:40 AM by Colas Nahaboo

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 34 replies on 3 pages [ 1 2 3 | » ]
Jim Waldo

Posts: 34
Nickname: waldo
Registered: Sep, 2002

Worse is worse (View in Weblogs)
Posted: Dec 9, 2003 6:58 PM
Reply to this message Reply
Summary
The classic essay on "worse is better" is either misunderstood or wrong. And in citing it in our design arguments, we short change both our customers and our craft. I revisit this essay, and reflect...
Advertisement

Recently, I was interviewed by a reporter who was doing a story on the difference between east coast engineers and west coast engineers (yes, that old chestnut is again being revisited). This in turn got me thinking about Dick Gabriel's classic note "Worse is Better", which is often credited with first articulating the distinction between the MIT (or east coast; after all, what else is there on the east coast) approach to engineering (do the right thing, no matter how complex it makes the code) and the Berkeley (or west coast) approach to engineering (make the code simple, even if it makes the user do more work).

The notion that worse is better has become something of a truism in the programming industry. The usual examples are the C language (worse than lisp, but it dominated anyway), Unix (or more recently, Windows) as opposed to Multics or VMS, and (in a completely different arena) VHS tape over Beta. Each of the dominant technologies, it is pointed out, was worse than the alternative, but the worse technology became the standard anyway. The moral to the story, or the reason that people bring the principle up in argument, is to convince whoever is on the other side of the argument that we should set our sights on the quick and dirty, less elegant solution to a problem, because "worse is better."

Of course, this received wisdom is just so much crap. The arguments simply don't hold up. But the damage that this principle has done to the technology industry is real, and we should start pushing back before we do any more harm than we already have done.

First, the arguments. Gabriel's original writing (which can still be found, like everything else, either through Google or by going here) makes an interesting read, and a number of good points. Reading it again not only reminds one of how well it is written, but debunks a lot of the usual common knowledge about the article. For example, the piece never contrasts the east coast and west coast engineering styles; the two groups it talks about are the MIT/Stanford style (one group) and the New Jersey style of design. Not nearly so interesting in these days as the notion that the contrast in styles is between west coast and east coast.

The rest of the paper is an excellent analysis for why Lisp lost out to C as a programming language, even though Lisp was a superior language. Or at least superior on the grounds that Dick found most important. But this doesn't necessarily show that Lisp was in fact superior to C; it can just as easily be taken to show that the metrics that were cited in the article were not the ones that were taken to be most important by those choosing a programming language. The fact that C produced faster code, was easier to master, was easier to use in groups, and ran well on less expensive hardware were not considerations that Gabriel found important. But others did. On those metrics, the dominance of C as a programming language was an example of better is better, not worse is better.

The old chestnut of beta and vhs is open to the same sort of alternate interpretation. On the "worse is better" interpretation, the superior quality beta was beaten out by the clearly inferior vhs tape format because of some inexplicable perversity of human nature (or the machinations of clever marketing people, or the hubris of Sony, who owned the Beta brand). But the vhs tapes were capable of recording longer programs on a single cassette, and could be played on cheaper recorders, and had a number of different suppliers. Thus there were a set of metrics on which vhs was the superior technology, and these metrics seemed to be the ones that most in the market found to be important. Vhs beat out beta not because worse is better, but better in some dimensions (cost, time to record) beat out better in other dimensions (picture quality).

Even the case of Unix vs. Multics misses an important point. While Multics may have been a better operating system, Unix had the twin advantages of actually existing, and running on a wide variety of fairly cheap hardware. Windows (and DOS) ran on even cheaper hardware, and though it was easy to argue on any technical grounds that you wanted that Unix was a better OS than DOS, the property of existence on really cheap hardware turned out to the the metric of goodness that appealed to the customer. The emergence of Linux as a real choice is beginning to give us more evidence in this particular choice; perhaps a better OS is something that people will choose when other things are equal. But when they chose DOS over Unix, things weren't equal.

In all of these cases, there is an alternate interpretation of the choices that were made that lead us to the conclusion that worse is not better. Instead, 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.

Of course, worse is better is a much catchier slogan than better depends on your goodness metric or some other, equivalent phrase that would actually reflect what was going on. And there is wisdom and insight in the original article that can be used by designers, even under the catchier (but less historically accurate) slogan.

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


Ian Phillips

Posts: 8
Nickname: ianp
Registered: Oct, 2002

Re: Worse is worse Posted: Dec 10, 2003 11:33 AM
Reply to this message Reply
Actually, the VHS vs. Betamax comparison is usually used as an example of why open standards (VHS) are superior to proprietary ones (Beta); even if the latter are technically superior the former will gain huge advantages due to network effects.

Ian.

Pete McBreen

Posts: 1
Nickname: petemcb
Registered: Dec, 2003

Worse is Better because my favorite lost Posted: Dec 10, 2003 2:03 PM
Reply to this message Reply
I like your interpretation of the Worse is Better article because it really does matter how you define better.

Most technical arguments fail to get past the stance that states that I like it therefore it must be better. The original article stood out because it highlighted all of the ways that Lisp was technically much better than C, even though, as you point out, the criteria that were selected were not the criteria that most people would use.

The old way of saying this would be "Horses for Courses", or "One size does not fit all", but to date it seems as if the software development community does not realize this. We are all so busy chasing the latest fad that we forget to make sure that the tools we are using are appropriate for the task.

Brandon Corfman

Posts: 14
Nickname: bcorfman
Registered: Aug, 2003

Re: Worse is worse Posted: Dec 11, 2003 12:15 PM
Reply to this message Reply
I read Gabriel's article for the first time about a year ago, and I didn't come away with your interpretation of it. My impression of what Gabriel was saying was that it's better to not spend the time getting things <i>perfect</i> because a) you may never release a product, b) your competition will already have released a product that fills the same need, and c) after that, your better product will never be able to grab enough mindshare.

This is true, and it's why the software industry has migrated toward more iterative (RAD/agile/TDD) development in recent years. You build a working design, get it to your customers, and then modify it after you see what they want. This has nothing to do with releasing poor software; it has to do with being responsive to users' needs.

I think this has always been the philosophy behind Lisp, although it stemmed from the needs of research, not professional application development. But it's an excellent philosophy. The problem was that Lisp the language is awkward, hard to debug and (back then) very slow. No wonder C won. When you put the same features in a pleasing, usable, C-like package (such as Ruby or Python), the public is much more accepting.

I just wish the Lisp people would get over it. Their excellent design principles have survived. Their language didn't. So what?

Steve Merrick

Posts: 1
Nickname: chaser
Registered: Dec, 2003

Re: Worse is worse Posted: Dec 12, 2003 4:55 AM
Reply to this message Reply
Thanks Jim, for a timely 'call to arms'. There's no particular threat; there never is. We just need shaking up from time to time. We need reminding that striving for better quality software is never a bad thing and never a waste of time. Thanks again, Jim! :-)

Ian Rae

Posts: 21
Nickname: ianrae
Registered: May, 2003

Re: Worse is worse Posted: Dec 12, 2003 11:38 AM
Reply to this message Reply
There are several aspects to 'worse is better'. For new techonology, such as video recorders, 'worse is better' often means technology that is affordable and practical is preferable. LISP had some great features but it crawled on a 286.

For replacement technology, where users have the choice of sticking with what they have, 'worse is better' reflects the tendency for new technology not to offer enough benefits to overcome the pain of migration. Currrent technology may be inferior but it's a devil you know.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Worse is worse Posted: Dec 12, 2003 7:39 PM
Reply to this message Reply
http://www.urbanlegends.com/products/beta_vs_vhs.html

Celia Redmore

Posts: 21
Nickname: redmore
Registered: Jun, 2003

Re: Worse is worse Posted: Dec 14, 2003 12:04 PM
Reply to this message Reply
The Worse Is Better argument is that most of the solutions which prove most successful over the long term are those which grow organically, rather than being well-engineered up-front. (Let’s remember that Gabriel examined both this theory and its converse.)

Gabriels’ point was that it didn’t matter all that much how good the original seed idea was. If an idea can be published in a relatively raw form, it will be knocked about and changed and may morph over time into something very good indeed. Linux is the poster child for this approach.

If you apply the Worse Is Better argument to Lisp versus C, it explains that it was the fact that Lisp was pretty well designed early on that prevented its being changed enough to become generally useful. Nobody had such inhibitions about C.

Evan Moses

Posts: 1
Nickname: hprotagoni
Registered: Dec, 2003

Re: Worse is worse Posted: Dec 15, 2003 7:52 PM
Reply to this message Reply
For example, the piece never contrasts the east coast and west coast engineering styles; the two groups it talks about are the MIT/Stanford style (one group) and the New Jersey style of design.

It is, in fact, comaring the cannonical East Coast vs. West Coast styles. The paper is comaring the MIT/Stanford approach, which, beacuse MIT is the East Pole (from which all points are west), is the East Coast, with Berkeley, which is the corresponding West Pole. The mention of New Jersey is a joke: he's not talking about anyone who does work in New Jersey. Rather, New Jersey is simply the butt of many jokes on the east coast (the "armpit of America"), and so he's naming it as the center of shoddy workmanship. It would be like someone at Stanford comparing the Stanford/MIT school with the Fresno school.

Dan Franklin

Posts: 1
Nickname: vorkosigan
Registered: Dec, 2003

Re: Worse is worse Posted: Dec 15, 2003 9:48 PM
Reply to this message Reply
> It is, in fact, comaring the cannonical East Coast vs.
> West Coast styles. The paper is comaring the MIT/Stanford
> approach, which, beacuse MIT is the East Pole (from which
> all points are west), is the East Coast, with Berkeley,
> which is the corresponding West Pole. The mention of New
> Jersey is a joke: he's not talking about anyone who does
> work in New Jersey. Rather, New Jersey is simply the butt
> of many jokes on the east coast (the "armpit of America"),
> and so he's naming it as the center of shoddy workmanship.
> It would be like someone at Stanford comparing the
> Stanford/MIT school with the Fresno school.

Is this a troll?? UNIX originated at Bell Labs in Murray Hill, New Jersey, and the "PC-loser" example discussed in the article was present in the original versions of UNIX developed entirely in New Jersey, before Berkeley ever saw it. Anyone who knows UNIX history would read the article this way.

Alex Garrett

Posts: 2
Nickname: ljagged
Registered: Dec, 2003

Re: Worse is worse Posted: Dec 15, 2003 9:56 PM
Reply to this message Reply
> I think this has always been the philosophy behind Lisp,
> although it stemmed from the needs of research, not
> professional application development. But it's an
> excellent philosophy. The problem was that Lisp the
> language is awkward, hard to debug and (back then) very
> slow. No wonder C won. When you put the same features in a
> pleasing, usable, C-like package (such as Ruby or Python),
> the public is much more accepting.

I would disagree with your assertion that Lisp is "awkward, hard to debug and ... slow". It's true that some people are put off by the parentheses, but once you get used to it, it's fairly intuitive. The power of sexprs lies in the fact that you're actually writing your code in an AST. The semantics are simple and unambiguous. And, because your code is already in an AST, it's easy to write programs that write/manipulate programs.

As far as debugging goes, I've had much more luck with the lisp debuggers than with using gdb to debug C. You'll never have your code fandango on core because of a char *foo = "Hello World/0"; do_something_stringish(foo); in Lisp.

Insofar as testing goes (and the power of macros and code introspection) here's a link to Peter Seibel's book-in-progress Practical Common Lisp where he writes a unit test suite similar to JUnit in 26 lines of code. (http://www.gigamonkeys.com/book/practical-building-a-unit-test-framework.html) One of the particularly nice points is that when an assertion fails, rather than simply turning your GUI bar red, it drops you into the debugger where you can examine and manipulate the stack to actually fix the problem. I've yet to see something like that in C.

As far as speed goes -- you're right that speed is less of an issue than it used to be. To emphasize the point, I'll mention that the folks at Naughty Dog are writing games for the Playstation2 in a dialect of Lisp: (http://lemonodor.com/archives/000610.html)

> I just wish the Lisp people would get over it. Their
> excellent design principles have survived. Their language
> didn't. So what?

It seems that Lisp is in a bit of a renaissance. There's some interesting Lisp and Scheme hacking going on right now. Greenspun's 10th Rule of Programming is still in force. DISCLAIMER: I'm not one of the "lisp people". I'm a Java programmer by profession. I've started to delve into Lisp primarily because of all of the shortcomings I've found in languages like Java, C, C++, etc.

Fu Bar

Posts: 1
Nickname: fubar
Registered: Dec, 2003

Re: Worse is worse Posted: Dec 16, 2003 12:33 AM
Reply to this message Reply
Hehe... I had not heard the "Worse is Better" argument before. It's like saying that "Evil will always triumph, because good is dumb.". It makes absolutely no sense.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Worse is worse Posted: Dec 16, 2003 5:54 PM
Reply to this message Reply
> If an idea can be
> published in a relatively raw form, it will be knocked
> about and changed and may morph over time into something
> very good indeed. Linux is the poster child for this
> approach.

Is it? Doesn't Linux have have a desktop share of under 1% compared with Microsoft's over 95%. For all its morphing, it has yet to morph into an operation system of choice for the general public and remains a niche product for political and technical specialists.

Vince.

Frank Mitchell

Posts: 37
Nickname: fmitchell
Registered: Jan, 2003

Re: Worse is worse Posted: Dec 16, 2003 11:42 PM
Reply to this message Reply
> Doesn't Linux have have a desktop share of under
> 1% compared with Microsoft's over 95%. For all its
> morphing, it has yet to morph into an operation
> system of choice for the general public and remains a
> niche product for political and technical specialists.

Even assuming your statistics, let's grade on a curve.

Until IBM jumped on the bandwagon, Linux had no marketing machine, no massive cash flow, no lucrative stock options to motivate programmers. What it *did* have was an ever-growing band of people who wanted their very own UNIX system on second-hand hardware, and before them the "political and technical specialists" who put their coding skills where their mouths were.

That Linux can even challenge Microsoft, already a juggernaut before Linus Torvalds cut the first line of code, demonstrates either the fragility of Microsoft's hegemony (as Mr. Gates reportedly believes) or the power of a sound design and motivated volunteers to unsettle a corportate behemoth.

Oh, and let's only count dominance on a desktop PC ... not, say, deployment as a platform for webservers, fileservers, and other infrastructure of the Internet.

Brandon Corfman

Posts: 14
Nickname: bcorfman
Registered: Aug, 2003

Re: Worse is worse Posted: Dec 17, 2003 8:45 AM
Reply to this message Reply
> I would disagree with your assertion that Lisp is
> "awkward, hard to debug and ... slow". It's true that some
> people are put off by the parentheses, but once you get
> used to it, it's fairly intuitive. The power of sexprs
> lies in the fact that you're actually writing your code in
> an AST. The semantics are simple and unambiguous. And,
> because your code is already in an AST, it's easy
> to write programs that write/manipulate programs.
> [snip rest of "why Lisp is great"]

These are standard arguments for Lisp to try to convince people to use the language. But my point is that C and C-like languages need no such arguments. The trends of the marketplace make all other arguments irrelevant.

Really, it's as irrelevant as someone saying, "Don't buy a DVD player -- laserdiscs are better." Add as many arguments of technical superiority here as you want ... what format is on the shelves when you go to the store?

My thinking is that rather and support Lisp itself (which I deem a lost cause), a better approach is to find a language that most closely resembles Lisp and that is thriving. For me, that language is Python.

Flat View: This topic has 34 replies on 3 pages [ 1  2  3 | » ]
Topic: Modeling to Avoid Hacking Your Model in ORM Mapping Format Previous Topic   Next Topic Topic: Rich Internet Applications: VM Runtimes or Browser Standards?


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us