The two pieces before this one dealt with config as a live production surface: changes that skip every check code goes through, and values assembled from so many layers that nobody can say what’s actually in effect. Both problems scale with the same quantity — how many settings exist. Which raises the question the earlier pieces set aside: why are there so many? The usual answer isn’t that each one was necessary. It’s that at some point a decision was hard, or contested, or simply not worth arguing about, and making it configurable ended the argument without resolving it.

That’s a real move with real appeal. Adding an option is fast, satisfies everyone in the room, and defers the cost to a future that feels abstract. But the deferral is not free and it’s not temporary. Every setting is a permanent branch in behavior that has to be kept working, tested in more than one state, documented, and reasoned about by everyone who touches the system afterward — including people who have no context on the original disagreement. The person who added it paid a minute. Everyone downstream pays a little, forever, and the sum is what makes a configuration surface unmanageable rather than any single knob.

There’s a specific tell for a knob that shouldn’t exist: nobody can say what value it should have or why. If the documentation says “controls the batch size” and nothing about how to choose, that setting isn’t providing flexibility, it’s providing an unanswered question with a text field attached. Genuinely useful settings tend to have an obvious owner and an obvious reason to differ — something that varies by environment, by customer contract, or by a constraint the system can’t know on its own. Settings that exist because the right value was unclear at design time tend to be left at their defaults everywhere, forever, which is the strongest possible evidence that the decision could simply have been made.

The alternative isn’t rigidity. It’s making the decision and letting the system adapt where it can. Many settings exist to compensate for something the software could determine at runtime — a pool size that could scale to observed load, a timeout that could derive from measured latency, a mode that could be inferred from the data. When the system can decide, the setting is a worse version of the feature: it demands a human supply an answer the software is better positioned to compute, and then goes stale the moment conditions change. Where a real choice belongs to a human, keep it — but pair it with a default good enough that most people never touch it, since a default is the decision you’re making for everyone who doesn’t have an opinion.

That’s the thread’s close: configuration is a design surface, not an escape from design. Each option added defers a decision, and the deferred decisions accumulate into a system whose behavior nobody can fully describe — which is exactly the condition the first two pieces described from the operational side, where changes bypass review and effective values become unknowable. Fewer, better-chosen settings make both of those problems smaller, and they cost only what was always the harder work: deciding, in advance, what this thing should actually do.