There is an email client for Linux called “Mutt” that became popular around the year 2000. It was very powerful, and it could be configured to work however you wanted; however, it also had to be configured to be able to use it at all. With the default configuration values, Mutt would do almost everything the opposite way a regular person would have expected. Whenever anyone recommended Mutt to you, they would always offer you their configuration file so that you could, at least, start using the program immediately.
We all know of a program of which, like Mutt, everyone says: “The first thing you need to do is go to the settings menu and change this.” That sounds like a terrible drawback: A program should work reasonably well with the default configuration.
At the butcher’s: “This is the meat I sell by default.”
Some configuration options have no reason to exist. I once saw an antivirus program that asked the user whether some files should be handled gracefully. That was the literal question it asked. I don’t know if the authors of that antivirus woke up one day and said: “You know, today I think we should make it so that whenever one of those files exists, the program does not work at all.” Neither do I know what the alternative was in their minds: have the computer explode?
The question is why so many programs do that.
Sometimes it’s just caused by the passage of time: a program does something in a particular way, but years later, users come to expect it to work differently, and the developers can’t change it lest their existing users, who are used to the previous way, get mad at them. To solve this dilemma, many developers add a configuration option so that users can choose the old or new way of doing things.
That’s not always the cause: Mutt was only three years old in 2000, and everyone was already swapping configuration files with their friends. In this case, it appears that the author of Mutt had preferences that didn’t match most users’ expectations. This happens much more often than you’d think, especially because many programmers are anything but humble, and they are incapable of entertaining the idea that their opinion would carry less importance than their users’ opinions.
And, finally, sometimes it’s just pure carelessness: the programmer adds a configuration option but doesn’t spare any thought for the default value, so they choose one randomly. This is not extremely common, but you can see it often in support forums and chat servers when the programmer says: “There is a configuration option; I don’t see what the problem is.”
As I mentioned, I think all programs should work reasonably out of the box. Their behavior should match what most users expect of a similar program, they should use colors and typefaces that are easy to read, and they shouldn’t have configuration options that cause them to stop working.
If you don’t know how to choose your programs’ default configuration values, I suggest polling your users (current and future). In practice, you don’t need to ask too many people to get statistically significant results; what you do need is humility to listen to and accept what your users tell you, especially when it goes against your intuition.
I want to make a final recommendation for you: avoid adding configuration options. Every new option introduces new places where a bug could hide, and it makes it harder to test your program: if there are three yes-or-no options, there will be eight combinations that need to be tested every time you want to release a new version of your program. Don’t be indecisive: choose an option and impose it, you cowards.
The illustration for this Coding Sheet comes from a cartoon by Honoré Daumier.