Quiet defaults.
A defense of software that does nothing until asked. Notes from three years of stripping features out of the same tool.
Most software has too many opinions. Not opinions that are stated — those are easy to argue with — but opinions that are silently baked into default states. The checkbox that is checked. The mode that is on. The feature that activates the moment you make an account.
The problem with defaults
A default is a statement about the world. It says: most users will want this. Sometimes that is true. Often it is a proxy for something else: what was easiest to ship, what the designer personally prefers, what the metrics team wanted to track.
The trouble is that defaults compound. Add three features each with a default-on state, and you have eight possible configurations — but users only ever see the one you chose. The hidden seven carry hidden costs: confusion, misuse, the overhead of having to undo things you never asked for.
Three years of stripping
The tool I have been working on started with twelve default-on settings. We are now at four. Each removal was a small argument — not about whether the feature was good, but about whether it should assume itself into the user’s context.
What I have learned from this: the question is not “is this useful?” It is “useful to whom, and when?” A feature that is useful to 80% of users at setup is actively harmful to the other 20% if they cannot easily turn it off. And the 80% often do not notice it is on.
The asymmetry
There is an asymmetry between adding and removing. A user who discovers a feature they wanted is mildly pleased. A user who discovers a feature doing things they did not want is actively disrupted. The calculus favors restraint — but only if you trust that users will find the feature when they need it.
That trust requires two things: discoverability and a sensible off state. If a feature’s off state is broken, it will never be off. If it cannot be found, it will never be on. Neither is worse than the other; both are design failures.
A working principle
My current working principle: every feature default should have a named justification. Not in code, not in a comment — in a decision record that a person wrote and signed. If no one can explain why a feature is on by default, it probably should not be.
This is slower than shipping. It is also, in my experience, faster than the support tickets.