People love configurable software.

They say flexibility is always good. More flags, more knobs, more environment variables, more ways to make the software fit every possible use case.

But in practice, configuration flags are often just a polite way to ship uncertainty.

A feature is added, but no one is completely sure it should be enabled by default. So, it gets a flag.

A behavior is changed, but backward compatibility is scary. So, it gets a flag.

Two users want opposite things. So, both paths stay in the code forever, behind a flag. At first sight, this looks reasonable.

Of course, a flag can be useful. Experimental features need a way to be tested. Migrations sometimes need a temporary escape hatch. And some software is genuinely used in environments that are different enough to justify a couple switches.

But temporary flags are rarely temporary. Once a flag exists, it starts attracting dependencies.

Documentation has to mention it. Support has to ask whether it is enabled. Bug reports have to include it. Tests need to cover both states. New features have to decide which side they are compatible with. And if the flag affects a file format, a protocol, or anything persisted, removing it later becomes painful. That is the real cost.

The code behind a flag is not one feature. It is two possible worlds that the maintainers now have to keep alive.

This gets worse when flags are not independent. One flag changes timeouts. Another one changes buffering. Another one changes concurrency. Individually, each sounds harmless. Together, they create a configuration space no one has actually tested.

Users then report that “it doesn’t work” on a setup that technically should be supported, but only with FAST_MODE=0, LEGACY_IO=1, the old parser, and a kernel old enough to vote.

Nobody designed that combination. It just happened. And now it is your problem.

A lot of software teams treat flags as free because adding a boolean looks cheap. It isn’t.

A boolean in the interface usually means a branching factor in maintenance.

This is especially obvious in open source. If a user asks for a niche feature, adding a flag feels like a compromise. The maintainer doesn’t have to bless the behavior as the new normal, and the user gets what they want.

But what actually happened is that the maintainer accepted long-term responsibility for behavior they may never use themselves.

The contributor will disappear. The flag will stay.

And five years later, some poor soul will ask why --compat-relaxed-fsync cannot be combined with the new backend on FreeBSD. Because software has memory.

The scary part is that flags often hide design problems.

If users regularly need a flag to disable a subsystem, maybe that subsystem is too eager.

If performance requires half a dozen tuning variables, maybe the defaults are bad or the architecture is brittle.

If a migration needs three generations of compatibility toggles, maybe the old behavior was never clearly isolated from the new one.

Flags can solve real problems. But they can also keep bad design alive by preventing the moment when someone has to say: this behavior was wrong, and it has to go.

Sure, removing options can upset people. But keeping everything forever quietly upsets the maintainers instead.

That cost is less visible, because it shows up as hesitation, slower releases, defensive coding, weird bugs, and documentation that reads like legal terms.

So, should software have no flags at all? Obviously not.

But flags should have the same status as debt: sometimes necessary, never free, and always suspicious.

Every new flag should come with an expiration story.

Why does it exist? Who needs it? What breaks if it goes away? When will that be acceptable? If nobody can answer these questions, the flag is probably not a feature.

It’s a fossil in progress.