DRAFT: Why, When Debating a Design Choice, To Never Say "Let's Make It a Setting!"

Title brainstorming:

  1. Never Imagine What Your Users Will Want [excessively provocative sounding]
  2. Choices are Bad
  3. Fight Against Settings Tooth And Nail
  4. Settings Considered Harmful

As you add more settings you increase the number of possible code paths and places for bugs to hide exponentially. It’s all too easy to add a setting due to uncertainty about what the right choice is and that’s really bad. If you’re sure that the setting is because of genuinely divergent use cases (and that you genuinely want to support both use cases) then maybe it’s ok to add the setting. My rule of thumb is to wait for a user to make an impassioned argument for their use case. Never add a setting speculatively, i.e., by imagining what a user will want. Default to total paternalism where you decide what the user wants.

Also things like documentation are easier the fewer settings there are. Also the fact that if you add a setting that turns out to be stupid, someone will get attached to it and it will be a big ordeal to get rid of it.

Related Reading:

  1. The xkcd about spacebar heating and breaking someone’s workflow
  2. Choices Are Bad
  3. Choices Are Really Bad
  4. The Paradox of Choice
  5. “Chapter 3: Choices” in Spolsky’s Guide to UI Design for Programmers has a hilariously argued case against adding settings for most things

Beeminder internal case study: https://github.com/beeminder/beeminder/issues/520