Worse-is-better
From Worse Is Better
The worse-is-better design philosophy, originally described in Richard Gabriel's article The Rise of Worse is Better, argues that for a particular technology to be successful, it is acceptable for that technology to trade interface simplicity (that is, ease of use) for implementation simplicity (that is, ease of implementation). Gabriel refers to this philosophy as worse-is-better, or alternatively the New Jersey approach.
The Reasons for Worse-is-Better
In order to argue for the idea of worse-is-better, we need to begin by considering the philosophy of "better-is-better" ("the-right-thing" in Gabriel's paper).
If you were to design a software system, ideally you would want it to be easy to use, feature-rich, and easy to implement. All good software in some sense attempts to achieve this ideal. The problem is that in practice it is all but impossible to develop a piece of software with all of these properties. Any complex system will necessarily have combinatorially many interactions with itself, and defining correct behavior for all these cases can be difficult or impossible. Some features that might be extremely useful to clients are often terribly difficult to implement, increasing development and testing time. On top of this, it's not always clear what features will be useful to clients, and so determining what the ideal piece of software might look like may be entirely infeasible.
The case for worse-is-better is that it prioritizes implementation simplicity in factor of ease of use and feature completeness. Rather than aiming for a complete solution the first time around, software designed with worse-is-better in mind will tend to support a core set of features with a mostly straightforward interface and correct behavior in most common cases. Although the resulting system will not be perfect, because it can actually be built it will be widely adopted and can then be improved into a completely-working system once it has achieved a stable user base.
Gabriel himself was critical of worse-is-better in his article, but conceded that in practice systems designed with worse-is-better in mind are more likely to thrive and flourish than technologies designed "the right way:"
I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy [...] However, I believe that worse-is-better [...] has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the [right thing].(Gabriel)
Notice that Gabriel does not say that software built with worse-is-better is inherently superior to programs built the-right-way; rather, programs built with worse-is-better in mind tend to spread more rapidly, build up a user base, and thus become entrenched.
Variations on Worse-is-Better
Since Gabriel's original article, the term "worse-is-better" has evolved to take on a variety of different meanings, all of which are generally related to Gabriel's original articulation but focus on slightly different aspects of the philosophy.
Gabriel concludes his analysis of worse-is-better with the following insight:
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.(Gabriel)
Although Gabriel himself later regretted this statement (see, for example, "Worse is Better is Worse", page 3, in which he concludes that "This advice is corrosive. It warps the minds of youth."), many software companies latched onto this particular interpretation of the worse-is-better philosophy. Facebook's Mark Zuckerberg, in an interview with the Business Insider, offered the following advice to entrepreneurs based on the Facebook philosophy:
Move fast and we used to write this down by saying "move fast and break things" and the idea was if unless you're breaking some stuff, you aren't moving fast enough. And I feel that's still basically true. [...] At the end of the day, the goal of building something is to build something, not to not make mistakes. [...] In order to get to any reasonable conclusion, you're going to make missteps along the way and as long as you learn from them and those become valuable in getting to where you want to go, I think that that's fine. (Zuckerberg)
In this interpretation of worse-is-better, it is advisable to build software as quickly as possible, even sacrificing correctness for the sake of a quick release. Getting to Gabriel's hypothetical 50% is important, even if the implementation isn't perfect and even if the software doesn't work perfectly well, because there's always time to make up the remaining percentage later "once people are hooked on it."
A variation of worse-is-better that we will not attempt to defend is the naive interpretation of worse-is-better that states that it is better to release inferior technology sooner than better technology later. This is too much of an oversimplification. Worse-is-better states that if necessary it is acceptable to reduce interface simplicity or functionality in order to achieve a simpler implementation, not that software should be released before it is ready.
Our Interpretation of Worse-is-Better
In light of the previous interpretations of worse-is-better, we propose our own definition of worse-is-better that we will refer to throughout this discussion. Given that we intend to attack this definition, we have taken great care to select an argument that we feel is true to the spirit of the many flavors of worse-is-better without being an obvious strawman.
Our particularly interpretation of worse-is-better is as follows: When tradeoffs are required in a software system, priority should go to implementation simplicity at the expense of completeness or correctness.
