If a default is the decision most people live with, there’s a companion question worth asking: why is this a setting at all? Options often get added not because users genuinely differ, but because the team couldn’t agree, or couldn’t figure out the right behavior, and a configuration flag let them ship both answers instead of choosing one. It feels like flexibility and generosity — let the user decide! — but it’s frequently the opposite: an unresolved internal argument, pushed onto people who have far less context than the team did and no particular desire to arbitrate.

The cost of that move is easy to miss because it’s spread thin. Every setting is a question the user has to answer, or at least notice and dismiss, and questions have a real cost in attention even when the answer is “leave it alone.” Every setting multiplies the number of states the software can be in, which means more combinations to test, more configurations to support, more ways for bug reports to arrive from a state nobody anticipated. And every setting is a small admission that the product doesn’t know what it should do — which is fine when the variation is genuine, and a quiet failure of design when it isn’t. The previous pieces argued that a default carries enormous weight; the corollary is that adding a setting to avoid choosing a default doesn’t dodge that weight, it just adds cost on top of it.

The distinction that matters is whether the variation is real. Some settings exist because users genuinely, legitimately differ: time zones, language, accessibility needs, scale of workload, regulatory environment. No amount of thinking gets you one right answer there, and offering the choice is doing right by people whose situations you can’t know. But plenty of other settings exist because two engineers preferred different behaviors, or because someone couldn’t decide whether the safer or faster path should win, or because a stakeholder wanted their preference preserved. Those aren’t variation, they’re indecision — and the fix isn’t a better default for the flag, it’s doing the work to determine what the behavior should be and then just doing that.

A test I find clarifying: can you describe the user who would change this setting, specifically enough to explain why their situation demands the other value? If yes — “a team running in a regulated environment who can’t allow this data to leave their region” — the setting is real, earn its keep, choose the default carefully. If the honest answer is “someone who prefers it the other way, I guess,” that’s a strong signal you’re shipping an unresolved argument. And a related tell: if you find yourself unsure what the default should be, that uncertainty is usually not about the default. It’s about not yet knowing the right behavior, which means the setting is standing in for thinking that hasn’t happened yet.

So the thread closes here. Defaults are decisions, made on behalf of the many who never choose. A wrong default is a mistake multiplied by everyone who never opted in, deserving scrutiny proportional to its reach. And the option itself is not a way out of either responsibility — sometimes it’s the right answer to real diversity in how people use your software, and sometimes it’s a decision deferred into a config file where it will sit forever, costing everyone a little attention and the team a lot of surface area. Fewer, better-chosen settings with carefully considered defaults is almost always a stronger product than a long list of knobs that document what the team couldn’t decide.