Comparison between worse-is-better and growable-is-better

From Worse Is Better

To substantiate our argument that growable-is-better is superior to worse-is-better, we have provided a comparison between the two design philosophies that highlights why growable-is-better does not suffer from the same limitations as worse-is-better.

The Cost of Deployment

The shortcomings of worse-is-better stem from the fact that the decrease in implementation complexity afforded to the programmer will ultimately be eaten up by the increased costs faced by end users. Any tradeoff of implementation simplicity for usability, no matter how small, will in the long run have a net cost (assuming, of course, that the software flourishes at all).

The motivation behind worse-is-better in the first place is that often "the right thing" is so difficult or time-consuming to implement that the resulting software would come out later than smaller, less polished solutions and thus have trouble establishing themselves. In the case of worse-is-better, the solution is to reduce the overall cost of the software development to ensure that the product is released earlier, even if this means having fewer features. Later on, the missing features may be added or bugs patched, but on a timetable set by the developers.

We can therefore restate the worse-is-better philosophy as

• When designing software, aim to release the smallest usable version of the software as fast as possible.
• Over time, begin adding in the features that were missing in the first release.
• Avoid implementing features that are needlessly time-consuming. There is no requirement that 100% completeness be attained.

The growable-is-better philosophy attempts to address the same problem from a different angle. The goal is the same - we want to decrease the cost of initially releasing the software. However, when doing so, the goal should not be to get the smallest workable version released, but rather a slightly larger version that allows for users to contribute to the growth of the project. This will allow the project to grow and the missing features to be added by the users in addition to the developers. Because these new features can be added in by the community at large and not just by the original developers, the rate at which the missing features will be added increases over time. This means that the extra cost incurred by using the software will start decreasing more and more rapidly as well, making the overall product more useful.

We can therefore restate the growable-is-better philosophy as

• When designing software, aim to release the smallest usable, growable version of the software as fast as possible.
• Over time, begin adding in features that will let the community grow the software more easily.
• Avoid implementing features that could be implemented by the community. There is no reason to implement it if no one will use it.

Building Useful Software

Another advantage of the growable-is-better approach over the worse-is-better approach is that it results in software that more accurately matches the needs of the community.

When building software with the worse-is-better model, the goal is to get a working piece of software out to the community as quickly as possible, even if some of the desired functionality is missing. Once this has been released, the remaining pieces can be added in piecemeal by the original designers. The issue is that once the software has caught on, there is no guarantee that the pieces added in to newer releases at all match what the community needs.

In the growable-is-better model, however, the enhancements to the product tend to be community-driven and thus match the demand. If the core developers focus on requested features that cannot be added by the community, then they will be focusing their efforts more precisely.

Lock-In Effects

If a new piece of software fills an unmet need, it will tend to take off virally and become a de facto standard. If the new software is well designed and growable, this tendency is beneficial, since it helps interoperability of systems and makes it unnecessary for users to learn how to solve the same problem over and over. Good standards help everyone.

But even if the design is poor and hard to extend, the first mover will often dominate the market. Microsoft DOS was almost certainly not the best operating system that would have run on personal computers in the mid 1980s, but it had a simple implementation and poor interface that fits Gabriel's notion of worse-is-better. Once IBM used it in their popular PC it became the industry standard for desktop computers through network effects: more software was written against it, so its market share grew and eventually set the stage for Microsoft to dominate the market with Windows in the 1990s. Once DOS gained momentum, there was no stopping it.

Since first mover and lock-in effects are so strong, software that gets a solution only partially right, even if it is not growable, will often be hard to replace. Since market forces do not allow the best software design to win, using a worse-is-better philosophy will often cause unnecessary work for the end users to work around the design flaws in these early designs.

If more engineers designed with growability in mind, this problem would be somewhat ameliorated. Once users identify the flaws, the community can often correct them.