Hm... when I think "worse is better" I'm not thinking of software that is "rock solid, fast, and small". Have I been misunderstanding the essay?

I thought most of these applications start out small but they're nowhere near rock solid and haven't been optimised for speed. It just gets the essential features in the hands of the people who need it and works just well enough to be useful.

Well, at least 70% of the HN crowd has been misunderstanding it.

The article has an anecdote in it where the "better" guy has grandiose ideas about wanting to make a perfect system that always does the right thing, even at a huge increase in implementation complexity.

In that specific case, not having to restart system calls after an interrupt. I've always thought the "worse" guy made the right choice by shifting the complexity out of the core, because we should deal with each problem in the place where it's most natural. There's nothing wrong with requiring users to make and use (or only use) a wrapper that deals with that complexity in one specific way that is right in the given situation.

I was surprised as well! But this is from the author so one can't argue with it.

As I think about it more, it makes a lot of sense. The only people willing to put up with something flaky are programmers. For most people, it can do little but it has to be reliable.

Also by the author (under a pseudonym), Worse is Better is Worse: http://dreamsongs.com/Files/worse-is-worse.pdf

> I’ve always told him that his penchant for trying to argue any side of a point would get him in trouble.

> Hm... when I think "worse is better" I'm not thinking of software that is "rock solid, fast, and small". Have I been misunderstanding the essay?

Have you read the 4 bullet points of the worse-is-better philosophy, in the beginning of the essay?

Yes. Simplicity of implementation is given priority over all other factors. This does not, to my mind, mean "rock solid" software (even if care is taken for "observable aspects" of correctness) unless we have very different definitions for the term.

It could be fast by virtue of having a simple implementation but that isn't a given. Sometimes getting speed is complicated, especially on modern processors.

I'm with you here. "Rock solid, fast, and small" is a better example of "less is more"

"Worse is better" implies lowered quality.

I understand "worse" as tongue-in-cheek. We also often see "stupid", "dead", "dumb", and similar things, as desirable qualities.

You are correct. The PCLSR facility given as the example of the MIT approach is faster and more solid than the Unix approach.

Which sounds like the "Unix Philosophy"

>Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".[0]

[0] https://en.wikipedia.org/wiki/Unix_philosophy