“Worse is Better”
Our Networks prof, Dave Beazeley , briefly mentioned a paper called “Worse is Better“(excerpt, full story) by Richard Gabrial, when discussing how the ISO-OSI model lost to ARPANET, even though ISO-OSI was better engineered, planned, etc, etc.
I had some time to kill last night, so I read up on the papers. The basic idea is that, when writing software (or anything else), there are two ways to approach it. One way is to plan, architect, and engineer the hell out of it so that it’s “done right.” The other way is to shoot for simplicity, even if it sacrifices completeness. Gabrial argues that C became more common than Lisp because C was easier to write a decent compiler for, allowing it to spread more easily.
What’s controversial (and this is something Gabriel himself apparently can’t decide either) is whether Worse is Better is actually better or worse. At the very least, the success of Open Source seems to vindicate Worse is Better to some degree. After all, “release early, release often” assumes that you can make good software by releasing something incomplete and improving it over time. Although this may depend on which area of the software industry you’re looking at, the rapid pace at which it moves probably favors those who deliver a solution that’s “good enough”, over those who deliver over-engineered solutions way too late.
At the end, I doubt there’s any straight answer to whether or not Worse is Better is better, any more than there’s an answer to the question: What’s the best programming language? In software, I think there are two quality measures: unusable and good enough. It’s really just a question of where you draw the line between unusable and good enough, and whether or not the Worse is Better approach can get you into the realm of “good enough”.
source: “Worse is Better”
