Why not add an option for that?

July 08, 2018

If you've ever developed software you've surely had users ask you to add an option. "Rather than forcing everyone into behavior A," they'll reason, "why not add an option so users can choose between behaviors A and B?"

This post is an attempt at producing a canonical consolidated answer to why the answer to this is often "no".

But first: it's worth pointing out that sometimes the right answer really is to add an option. The answer is not absolutely "no", it's rather "usually no, but maybe it overcomes the objections in this post". With that in mind, let's look at the costs of options.

Options are bad user experience

A great example of software with poor options UX is Git. Git is a tool with a simple clear conceptual core that's been absolutely wrecked by uncritical thinking around the design of the options. The git man page generator parodies this by generating ludicrous but plausible documentation for Git. There are plenty of other examples, though.

Options are features, and features are costly

You can think of software development as the accumulation of features over time. Spending time implementing the feature of my-new-option means that you are not implementing the feature of more-important-other-thing. The right way to look at the tradeoff is not "why not implement option X?" but rather "why implement option X instead of [more important thing I could be doing]?" Those other more important things could themselves be features or options but they also can be unobservable core work like making the software more efficient or crash less.

You might reasonably argue that an option is cheap — maybe just an extra if statement, maybe someone even wrote the patch already — but in practice there are more questions than that.

Writing the patch that adds the option ends up being a small part of the total work required, and the bulk of the work falls on whoever ends up maintaining the result.

Implementing a feature is a one-time cost, but keeping it working is an ongoing cost

Options can be costlier than features

In fact, as far as features go, optional behavior can be even worse for maintenance than always-on behavior, because options produce features that aren't consistently present.

If options are so bad, why do users want them so much?

Hopefully the above convinces you that new options aren't to be introduced lightly. So why do users so often ask for them? Here are a few reasons.

  1. Users are concerned about their particular use case, and tunnel on solving it without consideration for the whole system. "When I do X it takes three clicks," they think, "so you should add an checkbox like [] make it two clicks."

    This even comes up sometimes when a program has a genuine bug, like say it deletes the user's work in some circumstance, and the user will request "add an option to make it not delete my work" rather than the more obvious solution of not losing their work. (While drafting this post, I coincidentally had a perfect example of this come up — this user encountered a genuine bug and asked if there was a flag to suppress the bug.) There's a great xkcd taking this to the logical extreme, where the user demands an option to make the program waste CPU.

  2. Users see no cost, only benefits. If you ask a user "should I add a feature where ____?" they almost always will answer yes even before the blank is filled in.

Conclusion

If you're a user, even if you found this unconvincing, you can hopefully at least use it as a way to more successfully advocate for adding options to your favorite software. You can use this template: "Adding an option for A is more important than fixing bug B because C. It is impossible to design for this use case because D, it won't have much maintenance cost because E, and other users will know where to find it because F."

If you're a software developer, you already know that your responsibility is to balance all of the use cases simultaneously against other factors like opportunity cost and maintenance cost. It is my hope that at you can cite this essay as a way to avoid repeating the same arguments.