Worse is better: Innovation Revisited

"Microsoft won by putting out junk with a core good idea—and usually not their own idea—and then improved and improved, never putting out something too innovative, too hard to swallow, too risky."

"My thesis is simple: Invention, radical innovation, and great leaps forward do not produce revenue commensurate with the required effort in the software
industry, and invention usually doesn’t work in any industry."
--

In 1990 I proposed a theory, called Worse Is Better, of why software would be more likely to succeed if it was developed with minimal invention
(Gabriel 1990)
.
Here are the characteristics of a worse-is-better software design for a new system, listed in order of importance:
•
Simplicity
: The design is simple in implementation. The interface should be simple, but anything adequate will do. Implementation simplicity is the most
important consideration in a design.
•
Completeness:
The design covers only necessary situations. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized.
•
Correctness:
The design is correct in all observable aspects.
•
Consistency:
The design is consistent as far as it goes. Consistency is less of a problem because you always choose the smallest scope for the first implementation.
Implementation characteristics are foremost:
•
The implementation should be fast.
•
It should be small.
•
It should interoperate with the programs and tools that the expected users are
already using.
•
It should be bug-free, and if that requires implementing fewer features, do it.
•
It should use parsimonious abstractions as long as they don’t get in the way.
Abstraction gets in the way when it makes implementation too hard, too slow, or hides information that shouldn’t be hidden. (I once heard an interesting comment—sort of a motto—at a scientific computing conference:
Abstractions = page-faults.)
It is far better to have an underfeatured product that is rock solid, fast, and small than one that covers what an expert would consider the complete requirements.
These are the benefits of a software system designed and implemented this way:
•
It takes less development time, so it is out early and can be adopted as the de facto standard in a new market area.
•
It is implementationally and functionally simple, so it can run on the smallest computers. Maybe it can be easily ported as well—if it uses a simple portability model. At any given time the mainstream computer users—whether individuals or corporations—are running hardware at least two generations old.
•
If it has some value, it will be ported or adopted and will tend to spread like a virus.
•
If it has value and becomes popular, there will be pressure to improve it, and over time it will acquire the quality and feature-richness of systems designed another way, but with the added advantage that the features will be those the customers or users want, not those that the developers think they should want.
The path of acceptance is that the worse-is-better system is placed in a position in which it can act like a virus, spreading from one user to another, by providing a
tangible value to the user with minimal acceptance cost. There is little question it can run everywhere, so there are no artificial barriers. The system can be improved
by the end users because it is open or openly modifiable, and its implementation is simple and habitable enough that users can do this.
This simple implementation provides a means for the originators to improve the system over time in a way consistent with how it’s being used, thereby increasing
the magnitude of the most important evaluation factors. Over time, the system will become what lucky developers using a more traditional methodology would achieve.
This may seem counterintuitive—many people believe that being competitive requires doing the absolute best development you can. The following is a characterization
of the contrasting design philosophy, which I call
The Right Thing
:
•
Simplicity:
The design is simple, both in implementation and interface. Simplicity of implementation is irrelevant.
•
Completeness:
The design covers as many important situations as possible. All reasonably expected cases must be covered.
•
Correctness:
The design is correct in all observable aspects. Incorrectness is simply not allowed.
•
Consistency:
The design is thoroughly consistent. A design is allowed to be slightly less simple and less complete in order to avoid inconsistency. Consistency is as important as correctness.
There really is only one implementation requirement:
•
It should use hard abstraction throughout. Elements must be properly encapsulated in order to achieve information hiding.

The acceptance path for a right-thing system is that it is the right thing off the bat, and even though it came late to the marketplace, it is so wonderful that it is quickly accepted. Of course, it has to be on every necessary platform either right away or quickly. This scenario can happen, it is simply unlikely.

One of the more familiar examples of a right-thing system is the Macintosh and the Macintosh operating system. When the Mac was introduced in 1984 it was arguably the product of largely right-thing design though worse-is-better implementation. It used ideas and technology only 10 years old or so, and it was
considerably ahead of its competition. One might say that Apple tried to run up the score on the competition by producing a product so far in advance as to be almost not in the same competitive milieu.
Although one could argue that the Macintosh today—some 10 years later—is a success, it enjoys only about 10% to 15% of the total PC market. It is not used in the mainstream; rather, its strongholds are primarily in desktop publishing, graphic design, and marketing organizations, whereas Microsoft platforms are used throughout the corporation. There are many good reasons for this failure to capture more of the market in addition to the problems of the right-thing philosophy,
which we’ll look at further. MS-DOS was licensed to all the PC clone manufacturers, so that consumers had a choice of a variety of price and performance characteristics. Of course, IBM, having strong influence among MIS departments, helped seed the PC in mainstream settings.
The popularity of the PC and DOS created the opportunity for a market of software on this platform: A company wishing to write and sell a software product always looked to the PC and DOS first because it had a larger market share to start with because IBM shipped DOS, other manufacturers did too, and they all shipped the same platform.
----
The Macintosh was clearly superior, yet it lost. Among the reasons for losing was that Apple didn’t license its technology until 1995 so that a clone market didn’t appear earlier (and one could say that waiting 11 years to do it was a suboptimal strategy).
There are other problems stemming from the difference between the two philosophies.
One is that MS-DOS provided a simpler, more malleable base so that the aftermarket could more easily mold MS-DOS into what it needed. Once those characteristics of improvement were known, MS-DOS evolved.

http://dreamsongs.com/Files/Innovation.pdf