Inherited Defaults Are Decisions Nobody Made

Reviewing a database cluster’s configuration, I kept finding settings that were clearly wrong for the current version and workload — an outdated garbage collector, operating-system knobs left at values the software’s own docs warn against, a resource limit an order of magnitude too low. The striking part wasn’t that they were wrong. It was that nobody had ever decided on any of them. They were inherited: copied forward from an older version, left at whatever the distro shipped, carried in a template nobody revisited. They looked like configuration choices, but no human had chosen them. That’s the trap of inherited defaults — they wear the costume of decisions while being the absence of one.

Defaults pose as decisions

When you read a config file, every value looks intentional. Someone set the garbage collector, someone chose this memory limit — right? Often, no. The garbage collector was the default from a previous major version and got copied forward when the system was upgraded; the OS knob is whatever the base image happened to ship; the limit is a template value from a setup nobody questioned. The config file flattens “carefully chosen” and “never touched” into the same visual representation: a value sitting next to a key. You cannot tell, by looking, which settings are decisions and which are fossils — and that’s exactly why the fossils survive. They’re indistinguishable from intent.

A value in a config file looks like a choice. Half the time it’s just the thing nobody changed.

Three flavors of inherited default

The cluster I looked at had a clean sample of how stale defaults arrive:

• Carried forward across a version. It ran a garbage collector that had been the right default two major versions ago and was simply copied into each upgrade. The current version ships a better default; the cluster never adopted it because the old setting was explicitly present and overrode it.
• Whatever the platform shipped. An OS-level memory setting sat at the distro default — a value the database’s own documentation flags as an anti-pattern. Nobody set it badly; nobody set it at all, so it stayed at a default that’s wrong for this workload.
• Too low because it was never sized. A resource limit sat far below what a real workload needs, at a generic default that’s fine for a toy and a latent failure for production scale.

None of these is a mistake someone made. Each is a decision that never happened, and the default filled the vacuum.

Inheriting a default is not the same as choosing it

The reason this matters: a deliberately chosen value comes with a reason you can evaluate, and an inherited one comes with nothing. When you carry a setting forward, you also carry the original context — which may no longer apply. The garbage collector that was right for an old version on old hardware isn’t automatically right now, but copying it forward smuggles a stale decision into a new context with no re-evaluation. “It’s been that way and nothing broke” is not the same as “it’s correct” — it might just mean nothing has stressed it yet. Inherited config is unexamined config, and unexamined config is where latent problems live until load finds them.

Audit defaults against the current baseline

The practical move is to periodically diff your actual configuration against the current recommended baseline for the software and version you’re on — vendor docs, the project’s production-tuning guidance, the version’s new defaults. The goal isn’t to blindly adopt every recommendation; it’s to surface every place where your value differs from the current best-known one and force the question: did we choose this difference, or inherit it? A difference you chose, with a reason, is fine. A difference you can’t explain is an inherited default to fix or, at minimum, to decide on consciously. That audit is real work — it’s why config drift and stale defaults persist, because nobody’s job is to look. (And the cleanest way to keep them from drifting back is to express environment differences as deliberate config, not scattered code.)

Turn fossils into decisions

So when you inherit a system — or upgrade one — treat the existing config as a set of claims to verify, not settings to preserve. Walk the values that matter, especially the performance and reliability knobs, and for each one establish whether it’s a decision or a fossil. Adopt the current default where you have no reason to differ; keep your override where you do, and write down why. The point isn’t that defaults are bad — it’s that an unexamined default is a decision nobody made, sitting in production, waiting. It’s the same care behind getting sysctl drop-in ordering right instead of trusting whatever loads last. If you’ve found a setting running on pure inheritance long after it stopped making sense, I’d like to hear what it was.