When less is more | Hacker News Reader

When less is more

economist.com

69 pointsyan27 comments

I think the author misunderstood "Worse is better". Worse is not better because it is somehow more attractive to users. It is a better strategy, because by releasing early you get additional resources to continue building the big vision.

Consider company BigCo, which starts a massive $10mil project that will revolutionize the industry. It is epected to finish in five years. A small startup builds a little product for $1000 in a year, which implements one of the core features of BigCos vision. This is clearly a "worse" product. Using the revenue of $0.1mil, they enhance their product. This yields $1mil revenue after two years. Two iterations later the implemented BigCos vision in four years with just $1000 starting capital. When BigCo releases their final product it is already obsolete. This is how worse is better.

In the (Free) software world it isn't about money, but about users and developers. Gabriel tells a Lisp vs C example in "Worse is better", where "1987" is equivalent to the end of the five year period in my example: In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.

I don't think that even really captures what Gabriel was getting at.

The example he uses in the paper is from operating system design, where doing the "right" thing was too hard to implement. The "wrong" way is simpler to implement, and you get your OS written faster. Your OS now has a documented design flaw, and people have to work around it - but everyone does because you got your OS out first.

That is, he was more addressing design choices made when solving a problem. The full discussion is in his paper. It starts with the sentence "Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues.": http://www.dreamsongs.com/WIB.html

It's in fact hard to capture what Worse is Better was getting at, because it's sort of incoherent. I've tried 2 or 3 times to understand it over the years and concluded that, beyond the most general point (which you describe well, I think), it's not clear what he's really saying. I noticed Rich Hickey said this the other day, as politely as one possibly could: The arguments made in Worse is Better are very nuanced and I'm not sure I understand them all.

http://www.computerworld.com.au/article/313989/-z_programmin...

By the way, Dan Weinreb has an interesting piece in which he reveals that he was the MIT guy and Bill Joy the Berkeley guy:

http://danweinreb.org/blog/the-worse-is-better-idea-and-the-...

I recommend Kay Schluehr's comment on that page, which argues that arguments like WiB are drawing overly general philosophical conclusions from instances of success or failure in the market.

I think Richard Gabriel himself demonstrated that the points were nuanced, if not outright elusive, by writing a rebuttal to the essay with the title "Worse is Better is Worse" under the pseudonym Nickieben Bourbaki.

Gabriel's full account of the essays he's written is on his website: http://www.dreamsongs.com/WorseIsBetter.html

I went through a phase of reading all that stuff a number of years ago. Gabriel has a seriously pompous side, which I eventually couldn't bear any longer (probably after spending time and money tracking down his "Patterns of Software" book and then discovering how dreadful it was). But the piece you link to is refreshingly free of all that... until, amusingly, the last sentence, as if he falls off the wagon at the very end.

I don't begrudge him for being unable to make up his mind whether he agrees with "worse is better". There are disadvantages to both approaches. But there's no need to be a drama queen about it ("One fellow was seriously nervous that I might have a mental disease") or inflate it into an artificially large "philosophical" question.

I think the point is less about competitive advantages, and more that time is never irrelevant. What you want to maximize is, as it were, the area under the curve on the time-value graph. That means delivering a reasonable amount of value as soon as you can is going to be a better strategy than delivering no value for a longer time while you try to perfect things, then eventually delivering more value.

And since it's always a moving target, getting something that works "well enough" and then moving on to the next thing will always keep you ahead of people polishing their gleaming cube of perfection for ever more marginal returns.

I've probably posted this here before but...

Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way useful first, and then others will say "hey, that almost works for me", and they'll get involved in the project. --Linus Torvalds

Thank you for posting this again, fleaflicker. I have not seen it before. It's now on my bulletin board. I have a feeling it's going to make a big difference.

"This story is as old as the PC. Most of the time, what happens is that they give their program to a journalist to review, and the journalist reviews it by writing their review using the new word processor, and then the journalist tries to find the ‘word count’ feature which they need because most journalists have precise word count requirements, and it's not there, because it’s in the ‘80% that nobody uses,’ and the journalist ends up writing a story that attempts to claim simultaneously that lite programs are good, bloat is bad, and I can’t use this damn thing ‘cause it won't count my words."

http://www.joelonsoftware.com/items/2006/12/09.html

The problem is that businesses have to grow or they die, because they are competing with other businesses, and because they are heavily taxed and regulated. New features mean sales.

So it's mainly up to the consumers. As things are, if you want a simple product made with love, you generally have to pay a premium (e.g. solid wood furniture, swiss watch, etc.) Alternatively we could slow things down by all becoming late adopters.

On the positive side, feature creep drives progress. Most new features are rubbish, but every now and then one is found to be genuinely useful and it is quickly copied by everybody else.

Good point on the feature-creep leading to innovation. Maybe it's not all bad then!

But how can I find the one product without all the useless crap while others pay for the mistakes on the road to innovation? These features are still useless.

You gotta like an economist article including Lisp, Occam's razor and quotes from Einstein and Colin Chapman.

I think it is interesting how simplicity is a benchmark for the very best in so many different fields.

Science: Everything should be made as simple as possible, but no simpler. - Einstein. (actually an abbreviated version of a longer quote - go figure)

Writing: Brevity is the soul of wit. - Shakespeare

Mathematics: Consider Euclid's proof of the infinitude of primes.

Architecture: Consider Frank Lloyd Wright's work over his whole career going from relative complexity (prairie houses) to relative simplicity (Guggenheim Museum). Or the work of one of my favorite architects, I. M. Pei.

Comments on web pages: ... I think you get the idea ...

When proving a new theorem the first prove is usually ugly. Only later they get ever more nicer and simpler. Since the fame of mathematicians rests mostly on new stuff they discover, there's a saying that `mathematicians get famous on the ugly proofs.'

It's interesting in the domain of pro-electronics -- audio gear, photo gear, etc. -- you can often recognize the top of the line stuff by its relative lack of features. They start adding a bunch of junk to "pro-sumer" lines to make them impressive for people who want to look like a pro, but don't really know what they're doing.

Almost surprised there was no mention of the "less is more" Unix joke regarding the programs 'less' and 'more'.

UPDATE: (in the original Economist article).

There was; it got downvoted a few times and I guess the author deleted it.

I had a "less is more" thought when I was debugging my girlfriend's HTC Touch Diamond last night. It's a Windows Mobile smartphone, and she deleted a program. Then she kept getting an error on startup telling her a component was missing and to reinstall the program. I ended up having to delete a shortcut from the Windows\Startup folder to fix it. Sometimes I wish phones just made calls!

The problem is that Windows Mobile just sucks.

WM on HTC is pretty good. One of my major requirements is that a cellphone should be able to share its internet connection with my laptop. On the HTC that's easy (using bluetooth or USB, and it works with Vista,OS X,Linux). I'm in the market to get a new phone (and even move telco), but when I see the efforts involved in getting an iPhone, blackberry or Android device to do this kind of sharing/tethering, I just stick with HTC.

I just stick with HTC

You mean WM, but yes, this was a nice feature. Too bad nothing else on the phone was usable. (If you really want to tether, just get a dongle for your computer and save yourself the hassle. I find that Wifi is pretty much everywhere, though.)

The Flip Mino is one example that could use more features. Actually if you did not HAVE to use a tripod to remove shakiness, that would improve it ten-fold.

I think the problem is that product manufacturers try to make everyone happy with a single product. They gradually expand the product's definition in an attempt to get more and more people to use it. The problem is that one of the reasons why the initial users liked the product was that it was simple and didn't have a million features. So you start to lose them, or they like your product less.

I mostly agree with the article. On the other hand, adding more features isn't necessarily a bad thing in the case of the netbook as long as price and size/weight are still minimized or maintained.

I wish I had read this 2 weeks ago. Last night, I got my program working perfectly, but too slow! I quickly did some bench marking and immediately asked myself, "Why did I do it that way?" The answer: to get it to handle everything I wanted. I had feature creeped myself without even realizing it.

Back to the drawing board this weekend. Same core functionality, but much smaller footprint, and hopefully, much faster.

What about profiling? I hear that will often tell you what part of your program is slow.

I know what part is slow. I still can't believe I did it that way. It wasn't until last night when I put all the pieces together that I actually saw how badly it sucked. I was trying to be "slick" when I should have just done the job. Lesson learned (again).

Reply on news.ycombinator.com