Difference between revisions of "Opinion:Smart Software is Stupid Software"
(Created page with '<blockquote> <em>In the face of ambiguity, refuse the temptation to guess.</em> <p style="text-align: right">– Tim Peters, [http://www.python.org/dev/peps/pep-0020/ The Zen of ...')
Revision as of 19:58, 8 September 2010
In the face of ambiguity, refuse the temptation to guess.
– Tim Peters, The Zen of Python
A lot of software tries to be smart. This is a good thing, right? Well, it usually is not.
Software which tries to be smart usually takes a lot of input and makes an educated guess about some parameter. For example, a file viewer might examine the contents of a file, and based on properties decide how to display it (is it a text file or a binary file). While this seems useful, it is not. If it usually goes right, other software may rely on the behaviour, and it fails if the assumptions are wrong.
The situation might not be bad if just one software makes a guess, but a lot of guess may occur. Software may guess your location based on IP address or GPS data, and from that determine your time zone or preferred language. That choice might be wrong. Not every person living in France speaks French. A boot systems may determine all file systems on disks, and decides to boot in Windows, BSD or Linux by default. A file viewer may display a XML or base64 encoded file as text. A admin tool may parse a config file, and augment it with common default options, such as the location of a scratch file. A tool may determine the environment to determine what to do with log message (write to disk, show on screen or pipe to stderr). A package installer may probe for the best mirror site by determining the nearest mirror using round trip time, ignoring bandwidth constraints.
Each individual guess may not seem bad, but the problem arises when all these tools and applications start working together, and they do. A simple app on a computer involves not only the application, but also the operating system, a whole bunch of libraries, the network and computers at the other end of the network. If all these tools start guessing, the result is unpredictable.
This is not to say that every smart behaviour is wrong. Software may very well apply smart algorithms (in fact, a lot of software does so), but those algorithms must be well understood, and in case of the heuristic algorithms in the above examples, they are often not understood.
So what is the answer? Of course, we don't want to ask the user every time some input is unknown or unclear.
If the program interfaces to another program, demand strict input. If the program interfaces to the user, let the user fill in the preferences. Ask the OS for the preferred language, don't mix current location and language preferences, pick the boot system from a preference file, wait for user input (and store that result) if no choice was made. Look up the file type from whatever means is custom on the OS (file type attribute, file name extension or provided mime-type), asks the OS for the location of temporary files. log to a standard logging facility. Try mirror in a determined order, provided in a config file.
The smart part of the software comes from providing sound defaults when the user chooses the settings the first time. Not from guessing each and every time. In fact, the best programs are not smart in how they interpret the input, but smart how to deal with unusual situations. For example, how they deal with a broken network connection or deal with an OS which does not provide a given functionality.
We can make the life of a user easier by providing common functionality (such as location services, or a file type API) in the OS. Making smart guesses about these properties in each individual application is not the answer.
Computers are great in doing dull, mind-boring tasks. Humans are great in handling complexity. So let's design software on this principle, and not try to outsmart the user.