?

Log in

No account? Create an account

"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.

Comments

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.

I think what you're describing is the difference between engineering and architecture. When phenomenally successful software architects design something from the ground up, they design a system that guides its own development, so that everyone who looks at the system knows what needs to be included in the 50% that needs to be done after the first version is out the door. If this architecture piece hasn't been done, you have an incomplete system that's out the door with no indication of where it's going.

Unfortunately, a lot of marketing people never see (or often are incapable of understanding) the underlying architecture. This means that the people who make the marketing decisions often know when it's possible to let something out the door, but often don't know when it's safe to do so. I think what you're looking for is a way to evaluate what constraints are inherent in the design, and to extrapolate whether the constraints are sufficient to ensure that the product continues to develop in the way it needs to for long-term success and viability.

If you were to administer Richard Felder's and Barbara Solomon's Index of Learning Styles Questionnaire to a bunch of successful MIT engineers/architects, you would find that many of them are global thinkers/learners. Most of the population are sequential thinkers/learners, and their brains are simply not wired for keeping the big picture in mind as they develop the pieces, and putting constraints in place to keep the big picture on track.
Gabriel himself wasn't sure if it was true or not - he wrote several pieces arguing for AND against his own article (take a look at his own page about it: Richard P. Gabriel about Worse Is Better?

He said that he wrote it when he tried to bring LISP into a business environment and saw how different the business requirements were from the academic environment.

I would only use his argument in a business environment, describing noncritical systems. To refer to his paper in any other situation would be a cheap excuse to do sloppy work.

Coincidentally, have you looked at the principles of agile programming? I mean the spirit of it, not the execution?

software architecture vs. engineering

You may be interested in this paper on the history of software engineering by Michael Mahoney of Princeton. No solutions, but I found the history fascinating. I was a 6-3 major years ago (class of 1984), and wish I'd known about this sort of thing back then.

There are other similar papers here.