Applying the Baldwin Effect
A friend of mine mentioned the Baldwin Effect in conversation yesterday, and it set me thinking about the value of demos during the early stages of software development. Briefly, the Baldwin Effect is an evolutionary theory that learned behavior can eventually become built into the genetic makeup of a species. One of my professors explained it as follows, suppose there was a cat that learned to look both ways when crossing a street. It would naturally live longer than cats that didn't, at least city cats. What if this cat also taught this behavior to its offspring? Eventually a fitness landscape would be created that favored cats that looked over those that didn't. If a mutation for looking both ways arose at this time, it would find an environment in which it would naturally flourish. In effect, behaviors can eventually become built-in. This has been investigated with lots of math that I can't follow.
My interest is its application to software, and specifically the relation between demos and design. When a new product is first created there are expectations about what it should do, but nobody knows exactly how it should be used. In time a common pattern of usage evolves, which is taught by experienced users to novices. This pattern becomes the assumed behavior which is then copied by competitors. New features accumulate along this usage path until the product is what the original demo showed it to be.
A classic example of this is VisiCalc. It was originally an electronic sheet of paper, which could be used for many things, including managing financial tables. The early demos taught to salespeople were based on the profit and loss example we all know so well. In time this demo became the assumed pattern of usage, and the product was known as a spreadsheet. All of VisiCalc's competitors focused on features that made a better spreadsheet, resulting in the spreadsheet metaphor we now all use.
The principle that "the software becomes the demo" is especially important in a start-up. Since software is so plastic, there is often a competition to incorporate everyone's pet feature. If a good demo is developed early, even if many of the features don't work yet, it can serve as a focal point for new features. If a feature makes the demo better include it, if not don't. This rule can still be applied to webapps, even if there are few chances to actually demo the software directly to a user. Even if the demo is only used in-house and with investors it can still serve as a beacon for developers, continually pointing them back to the planned course.
