“It is far better to have an under-featured product that is rock solid, fast, and small than one that covers what an expert would consider the complete requirements.”
https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf (pg 219)
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.
"Worse is better" implies lowered quality.
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.
> I’ve always told him that his penchant for trying to argue any side of a point would get him in trouble.
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.
Have you read the 4 bullet points of the worse-is-better philosophy, in the beginning of the essay?
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.
>Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".[0]