Sam Hartman (hartmans) wrote,
Sam Hartman

"The Rise of Worse is Better," isn't

In 1991, Richard Gabriel published "The Rise of Worse is Better", one of the most depressing papers I've ever read. It concludes:
The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.
I found the paper depressing because at least the naive reading argues against correctness and actually solving the hard parts of the problem at hand. The admission that with this philosophy, you'll probably never get beyond a 90% solution no matter how hard you try is something I've found particularly dismal. All too often I find something I care about is in that last 10%.

The thing that really bothers me about the paper is that the tone doesn't really seem constructive. There is a constructive way to talk about the lessons there: incremental design, the value of implementation experience, etc. This paper doesn't. Unfortunately, at least in the MIT culture, it's also become a cornerstone of how we think about systems design. And of course, there really is something to be learned from Gabriel.

I was thinking about "Worse is Better," again recently because it came up as a justification for some dubious design choice in a SIPB office discussion. We pulled out the paper and discussed the conclusion. I realized that all my bitterness focuses on two words—"often undesirable." When is it undesirable, Mr Gabriel, and when am I starting a long path that ends up at a brick wall? I expressed this frustration and someone pointed out that I was expecting too much. This was the first paper; it practiced its own philosophy and was an incomplete answer.

I'd never thought of things that way. Ironically, this seems to be one of those rare cases where we get half of a right thing, it spreads like a virus and we never bother to finish it up. oops.

I actually think that we as software engineers have somewhat of an intuition about how much you have to build in from the beginning before starting your process of incremental design. I've just not found anything that does a good job of characterizing this or studying the implications of getting various parts of a system done before it gets out there. Note that this is different from studying what parts of a system you need to get done before you can achieve market success by getting it out there. I'm talking about what you need to do in order to create the necessary evolutionary path from where you are today to some unknown point in the future. I'd love to find something more than intuition as guidance.


  • Making our Community Safe: the FSF and rms

    I felt disgust and horror when I learned yesterday that rms had returned to the FSF board. When rms resigned back in September of 2019, I was Debian…

  • Good Job Debian: Compatibility back to 1999

    So, I needed a container of Debian Slink (2.1), released back in 1999. I expected this was going to be a long and involved process. Things didn't…

  • Forged Email

    Last night, a series of forged emails was sent to a number of places around the Debian, Ubuntu and Free Software communities. The meat of the mail…

  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.