Configurability is often sold as a feature. Give the user knobs, the argument goes, and they will tune the tool to their exact situation. Everybody wins: the tool serves more use cases, the user feels empowered, the surface area expands.
The argument is almost entirely wrong, and the tools we love most tend to prove it.
What a knob actually is
A configuration option is not a feature. It is a promise. It says: this behavior is stable enough that you can rely on tuning it, and I will keep the tuning working across every future version of the tool. Once you ship a knob, you cannot quietly delete it. You cannot change its default without breaking someone's carefully tuned system. You cannot deprecate it without a migration path.
Every knob is, in other words, a permanent obligation. And obligations compound. A tool with fifty knobs has fifty obligations, and every future decision has to route around all of them. The tool becomes a museum of past commitments, curated by an increasingly reluctant maintainer.
Why users ask for knobs
Users ask for knobs when the tool is close to right but not quite. The knob feels like the cheapest fix — a small adjustment, a personal preference, a one-line addition. From the user's side, it is the cheapest fix.
From the tool's side, it is the most expensive one. The user is asking you to convert a design decision into a design surface. Every future version of the tool now has to accommodate their preference, plus everyone else's, plus the interactions between them. The cost is not paid by the person requesting the knob. It is paid by every future user of the tool, forever, in the form of a slightly more confusing surface.
The alternative to configurability
The alternative is opinion, held firmly and explained clearly. The tool decides. If the user disagrees, they use a different tool. This sounds arrogant when written down, and it is, but it is the arrogance that produces coherent software.
The most beloved tools in most categories are the opinionated ones. They are not the tools with the most options. They are the tools whose defaults are so well-chosen that most users never notice they are defaults at all. When you use one of these tools, you are borrowing someone else's taste, and if their taste is good, the borrowing is the point.
Configurable tools ask you to bring your own taste. This is fine when your taste is well-developed and specific. It is exhausting when it isn't, which is most of the time, for most users.
When configurability is honest
There is a legitimate case for configurability, and it is narrower than the industry pretends. Configurability is honest when the axis being exposed is a genuine input to the problem, not a mask over an unresolved design decision.
A build tool should let you configure your build targets, because your build targets are a real input. A build tool should not let you configure the shape of its output tree, because the output tree is a design decision the tool should have opinions about. Exposing it as a knob is the tool refusing to decide, and pushing the decision cost onto every user.
The test is simple: if you cannot pick a good default, the knob is a design failure disguised as flexibility. If you can, expose the default and, in most cases, don't expose the knob.
What this means for building things
We think about this a lot at Fewzon, because the temptation to add knobs is constant and the pressure to add them is high. Every early user has a specific situation, and every specific situation looks like it deserves its own option. Saying no is unpopular. Saying no is also the only way to end up with a tool that has a coherent shape three years from now.
The rule we try to follow is this: before adding an option, we try to add an opinion instead. Sometimes the opinion is wrong and we have to revisit it. That is cheaper — much cheaper — than shipping a knob and inheriting its obligation forever.