What “Worse is Better vs The Right Thing” is really about

Linus' and Alan's citations aren't incompatible. Actually, I think they're both true. Yes, massively parallel trial-and error works wonders, but if you favour the first solutions, you'll often miss the best ones. Actually, effects such as first time to market, backward compatibility, or network effects often trump intrinsic quality by a wide margin. (Hence X86's dominance on the desktop.)<p>Yes, Worse is better than Dead. But the Right Thing dies because Worse is Better eats its lunch. Even when Worse actually becomes Better, that's because it has more resources to correct itself. Which is wasteful.<p>The only solution I can think of to solve this comes from the STEPS project, at <a href="http://vpri.org" rel="nofollow">http://vpri.org</a> : <i>extremely late binding</i>. That is, postpone decisions as much as you can. When you uncover your early mistakes, you stand a chance at correcting them, and deploying the corrections.<p>Taking Wintel as an example, that could be done by abstracting away the hardware. Require programs to be shipped as some high level bytecode, that your OS can then compile, JIT, or whatever, depending on the best current solution. That makes your programs dependent on the OS, not on the hardware. Port the compiling stack of your OS, and you're done. If this were done, Intel wouldn't have wasted so much resources in its X86 architecture. It would have at least stripped the CISC compatibility layer over it's underlying RISC design.<p>But of course, relying on programmers to hand-craft low-level assembly would (and did) make you ship faster systems, sooner.

Great essay -- I agree with its main point: "worse" products triumph over "the right thing" when they are a better fit for the evolutionary and economic constraints imposed by an evolving competitive landscape.<p>Some examples:<p>* In the case of the rise of Unix, the market of the 1960's and 1970's valued simplicity and portability over "correct" design.<p>* In the case of the rise of the x86 architecture over the past three decades, the market valued compatibility and economies of scale over the simplicity and elegance of competing RISC architectures.<p>* In the case of the current rise of ARM architectures for mobile devices, today's market values simplicity and low-power consumption over compatibility with legacy x86 architectures.

I never really got the "Worse is Better" essay. It obviously doesn't mean what everyone says it means and what it does mean isn't clear. This post points some of that out. For example, Worse in the essay was associated with simplicity. But the classic examples of Worse triumphing in the marketplace (the OP cites x86 as an example) are anything but simple: they are hypercomplex. Not only that, their complexity is largely what <i>makes</i> them Worse. Simplicity is rather obviously Better, not Worse. Smalltalk (which the OP cites as Better) is far simpler than its more successful peers. The more you look at the original essay, the more its conceptual oppositions seem muddled and at odds with history. I've concluded that it boils down to exactly one thing: its title. "Worse is Better" is a catchy label that touches on <i>something</i> important about technology and markets and means different things to different people.

I often think about software development in similar terms -- evolution versus intelligent design.<p>The weakness of evolution is that it takes millions of years, it's heavily dependent on initial conditions, there's lots of collateral damage, and most lines die out.<p>The weakness of intelligent design is that we're only so intelligent, which places a pretty low limit on the possible achievement. (And intelligence is generally regarded as close to a normal distribution, meaning that the smartest people can only handle a small multiple of the complexity of the average person).<p>Obviously, evolution and design need to be combined somewhat. The question is: how much of each, and at what times during a project? Do you spend 10% of the time quietly planning, 10% arguing with a small group of designers, and 80% trying things and trying to get feedback? Or is it more like 40%, 40%, and 20%? And how do you mix trying things with the designing things?

Thank you Yossi for writing this piece. It's about time that Worse is Better argument was debunked. Worse isn't better, portable, free (libre, gratis, or at least really cheap) is better.<p>What many people forget is that during the time frame Worse is Better talks about, Lisp machines cost as much as two or more houses. You couldn't get a decent Lisp system on affordable hardware until MCL, and then you still needed a fairly high-end Mac to run it on.<p>OTOH, Unix and C-based software ran on a bunch of different machines, which you either already had or could acquire inexpensively. The software was easy to get and inexpensive as well. Then 4.3BSD and Linux came along, and you couldn't beat that on price.

Interesting to note, in this connection, the rising popularity of Haskell, which is <i>way</i> off at the "Right Thing" end of the spectrum.<p>Maybe it is really possible to come up with the Right Thing eventually -- it just takes a lot of research.

An enjoyable and stimulating read. The original essay, by virtue of a few semantic ambiguities (what is "simple" anyway?) is apt to invite this sort of commentary.If I have read this correctly, the author eventually agrees that worse really is better, with the clarification on what this means outlined in the first part of the essay.<p>However, I was hoping to see a deeper analysis of how the nature of the evolutionary pressure in his domain contributed to the worse is better effect (I am an evolutionary biologist, so I find this kind of thing interesting). For example, if the "product" in question was a mathematical concept of interest to professional mathematicians, there almost certainly be a niche space in which version of the concept exhibiting "consistency, completeness, correctness" will dominate over the competition. For mathematicians consistency and correctness are strongly selected for (completeness, broadly defined, is usually much harder to obtain). For a the average iPhone app, these things still matter, but in a very indirect sense. They get convolved (or low passed, as Alan Kay describes) with other concerns about shipping dates and usability and so on. I would be interested to see a classification of different domains in which "worse is better" and "the right thing" philosophies dominate, and those in which they are represented in roughly equal proportions.

It's not too instructive to look back on things that occurred mostly due to happenstance and try to assign reasoning to it.<p>And it's a bit of a stretch to associate Linux with "Worse is Better." A major reason for using Linux in the early days was that it was the best alternative to Windows 95 because it got process isolation on x86 right.

This actually reminds me of the Plato/Artistotele difference. Plato held that there was an ideal, perfect version of everything in a sort of Idea Heaven, and the goal of the philosopher was to get ever closer to understanding that ideal.<p>Aristotele, on the other hand, thought that Heaven was too remote, and held that we could learn more by measuring what we see in this world. As opposed to the presumably ideal, but unaccessible, concepts in Heaven.<p>The medieval church loved Plato, the scientific revolution loved Aristotele.<p>My point is that the difference between these two frameworks for interpreting the world seems to be fundamental. Fundamental in the sense that the distinction has been with us for at least a couple of milennia, and we are apparently not likely to agree on a single answer anytime soon.

I try really hard to not take a left vs right view in software design.<p>I sometimes build systems that are overengineered and I sometimes build systems that are underengineered.<p>I do believe that every line of code, every function, every class, every comment, every test, everything, is like a puppy that you have to take care of.<p>If a team adds a "dependency injection framework" that adds a parameter to each and every constructor in a system that has 800 classes, which that's a real cost that's going to make doing anything with that system harder.<p>I'm a big believer in "cogs bad" because I've seen large teams live the lesson.<p>From my viewpoint the perfect system is as simple as possible, but well engineered.

Another way to put this is that myopically optimizing for perfection along one axis may fatally de-optimize another.

My angle at the problem is the concept of "engineering debt": if a well-designed product is the state of being "debt-free", and a deviation from good design is a unit of "engineering debt". That debt will have to be serviced in the form contortions you have to make to work around the design flaws, and then eventually paid down in the form of rewrite, or discharged in an engineering bankruptcy (such as abandoning the product).<p>Engineering debt, much like financial debt, is an instrument one can use to trade some present-point expenditure for a larger future expenditure. Where one makes sense so often does the other.<p>Sadly, engineering debt is much harder to account for. Old companies are carrying huge amount of debt and are often times oblivious to it.<p>I think we could advance the state of the art if were to find a way to quantify engineering debt. As a starting point I suggest a ratio of line changes aimed at servicing vs. line changes aimed at creating new features. If 100 lines of new functionality require 10 lines of base code changes, the debt is low. The opposite is true, the debt is high. I believe such metric could speak to both business managers and engineers, so it provides a good common ground for the two groups of reach consensus and prioritize work.

I just don't think "simple" is quite the right word for Worse is Better.<p>"... It's called Accessibility, and it's the most important thing in the computing world.<p>The. Most. Important. Thing.<p>..."<p><a href="https://plus.google.com/112678702228711889851/posts/eVeouesvaVX" rel="nofollow">https://plus.google.com/112678702228711889851/posts/eVeouesv...</a>

I think the lesson is, "whatever is available tends to propogate, even if it is shit. Especially if it is for a large mass of humans, who tend to act stupidly in mass."<p>You can see it all over the place. How great of an Internet provider was AOL, for example?

If he is a perfectionist and has been for many years, then his worst can only be so bad...

There are so many generalizations in this article I don't know where to begin...