The introduction of a new paradigm in software development is almost always more properly a recognition and codification of principles that developers have honored intuitively for years, and the one I’m about to propose is no different in that regard. Developers of both end-user applications and software development tools have often observed that the consumers of their productions are likely to:
- be uncertain about how to begin
- make common errors when using the product
- attempt to use the product in ways other than the purposes for which it was designed
Developers have haphazardly employed a number of tactics to remedy these ills. I hereby propose a systematic strategy to insure that not one user goes astray, which I call Stupidity-Oriented Development (SOD). SOD includes the following helpful practices:
Put the user in a box and keep him/her there
Make the usual things simple, and the unusual things impossible. Don’t think of this box as a prison, but rather “a fortress deep and mighty, that none may penetrate”. Users can’t hurt themselves if we only allow them to achieve certain things that we know in advance aren’t harmful. The best examples of this principle are graphical wizards that include only the options that are reasonable. Rather than rapping the knuckles of a wayward user with an error message, we simply make it impossible for him/her to perform the wayward act. If they express a desire to pursue an option contrary to our guidance, the correct response is: “that’s unsupported.”
Make the user repeat his/her intentions
It is axiomatic that the most frequent mistakes in software development are type errors. Not even highly-skilled developers can write so small a program as “Hello world” without trying to pass a
string where a
Microsoft.Playthings.World object is expected instead. Languages that employ SOD solve this problem with static typing — the developer must state the type of object expected, and then must also type the object that is passed using a compatible class. By forcing the developers to repeat themselves in this fashion, the compiler can check both statements for consistency, and stop them from pursuing their momentary insanity. In recent years, though, this safeguard has been increasingly threatened by a new laxity that goes under the name of type inferencing. This dangerous development sprints down the slippery slope of assuming that developers mean what they say.
Lead the user down the right path
Perhaps the single most SOD-like feature ever implemented on a large scale was Microsoft Office’s most famous assistant, Clippy. Clippy’s animation appealed to the playful tendencies of the human brain, and cheerfully offered to help the user do the things s/he should do, rather than what s/he wanted to do. Alas, Clippy was ahead of his time, and failed to achieve the unsurpassed popularity he deserved. Some analysts have attributed this failure to the work-related image of a paper clip, but later incarnations as a puppy, wizard, or genie did not fare any better. Perhaps if he were reintroduced as a Nyan Cat or Gangnam Style dancer, he might be better able to command user attention.
All of the above practices share a common theme: using well-designed silicon-based intelligence to guide and correct the inferior carbon-based intelligence that evolved purely by chance within human skulls. While not a perfect solution, it is the best we can do until the latter can be replaced totally by the former.