Defaults and Constraints

I read an article in Scientific American Mind, “When Words Decide” by Barry Schwartz, about how the phrasing of a question or proposal can dramatically alter the way people answer it.

Among the examples was the astounding difference in organ donor rates between countries with an opt-in policy (where you must sign a form in order become an organ donor upon death) and those with an opt-out policy (where you must sign a form in order not to). As you can probably guess, in countries with an opt-out policy, organ donor rates were much higher: from eyeballing the graphs, it looks like about 95% in opt-out countries, but only about 15% in opt-in countries.

Beyond simple laziness of avoiding the extra hassle of signing a special form, the author suggests that people accept the default because they perceive it as being the recommended choice. Unless they have some special reason to go against the flow, they usually won't.

Upon reading this, it occured to me that one of the brilliant things about Rails is the way it directs the flow through its use of defaults and constraints. It's very easy to create a working application with Rails, because the stream is carrying you towards one anyway.

Defaults and constraints are two sides of the same coin. While constraints make it harder for you to go against the flow, defaults make it easier for you to go with the flow. (To put it yet another way, a default is a tour guide leading the way, while a constraint is a security guard preventing you from wandering into a restricted area.)

Both defaults and constraints can be inspiring and liberating as a creator, though I'm not quite sure what it is about them that makes it so. Perhaps it's the fact that they give you a jumping-off point. But not all defaults and constraints are helpful and positive; some are stifling and discouraging.

Helpful defaults seem to have two qualities:

1. In most cases, the default is what you wanted anyway.
2. It's easy to override the default in special cases.

Helpful constraints have two corresponding qualities:

1. In most cases, it's advantageous to obey the constraint.
2. It's not impossible to circumvent the constraint in special cases.

Harmful defaults or constraints break those qualities. The worst default is one that is never what you want, but is impossible to override. Likewise, the worst constraint is one that denies you some advantage, but is impossible to circumvent.

For the most part, both Rails' defaults and its constraints are helpful, although there are a few of them that are a bit too difficult to override/circumvent.

As for applying this lesson to Rubygame… it's definitely showing up in the work I'm doing with event hooks in the development-3.0.0 branch, and I'm quite pleased with how it's going.