A shared infrastructure component has grown a boolean or environment-name input for nearly every per-environment difference. Why is that a problem, and what would you do instead?

## How it happens Nobody designs this. It accretes. Production needs a replica; add `enable_replica`. Dev should not pay for backups; add `enable_backups`. Staging needs a public endpoint for a partner test; add `public_endpoint`. Each addition is individually reasonable and takes five minutes. Two years later the component takes forty inputs, half of them booleans, and reading it means holding a truth table in your head. ## Problem 1: untested combinations With *n* independent booleans there are 2^n possible shapes. You use three of them — one per environment. The rest have never been instantiated, which would be fine if they were unreachable, but they are not: they are one review away, and the day someone flips a flag in a hurry they instantiate a combination that has never existed anywhere. Worse is the asymmetry. The flags that are *on* in production and *off* everywhere else describe exactly the code path that has never run in a safe environment. The abstraction is thinnest where the consequences are highest. ## Problem 2: the component now encodes policy A reusable component should describe *how to build a thing*. Once it contains `if environment == "prod"`, it also describes *what your organisation does in production*, which is a completely different kind of knowledge with a completely different rate of change. Two consequences follow. The component cannot be reused by a team whose environments are named differently without editing it. And the policy is now invisible to anyone reading the environment's configuration — the call site says `environment = "prod"` and gives no hint that this quietly turns on cross-region replication and seven-year retention. An environment-name input is the worst version of this, because it is a flag that fans out to many behaviours at once and hides every one of them. ## Problem 3: reviewing a change becomes simulation To review a change to a heavily conditional component, you cannot just read it — you have to mentally execute it under each environment's flag set. Reviewers stop doing that quickly, and then the component is effectively unreviewed. ## What to do instead **Parameterise values, not the presence of resources.** This is the single most useful line to draw. `instance_size`, `replica_count`, `retention_days`, `cidr_block` are values; every environment takes the same code path and supplies different numbers. `enable_replica` is not a value — it selects between two structures. When `replica_count` can be zero, you have often converted a structural flag into a scalar, and that is a real improvement. **Push structural differences up to the caller.** If production needs an extra piece of infrastructure, let production's configuration compose that extra piece explicitly. The shared component stays one shape; the difference is visible at the site where the decision was actually made. ``` before: service_component(env = "prod") # component decides, invisibly after: service_component(size = large, replicas = 3) plus, only in the prod composition: replica_component(...) # the difference is on screen ``` **Split the component.** If two callers use disjoint halves of the inputs, they were never one component. Two smaller, coherent components — each with a small honest interface — beat one that covers both by branching. **Accept duplication.** The least popular and often the correct answer: two explicit definitions can be cheaper than one abstraction contorted to cover both. Duplication costs you a change applied twice, which is visible and mechanical. The wrong abstraction costs you every future reader's comprehension and every future change fighting a shape that does not fit — a much larger bill, paid silently. Extract the abstraction later, once the two cases have stopped diverging and you can see the real shared shape. **Presets over flags.** When several inputs move together, a small named set of input bundles — one per environment tier, defined at the caller — beats individual flags. The bundle lives in the environment's configuration where it is readable, rather than inside the component where it is not. ## The honest caveat Some flags are legitimate. A component supporting two genuinely different but equally supported modes — public or private endpoint, say — with both modes exercised by real consumers and documented is fine. The defect is not conditionals; it is *unexercised* conditionals encoding environment policy inside a unit that is supposed to be environment-agnostic. The test question is simple: **is this code path instantiated somewhere other than production?** If not, it is not an abstraction, it is a production-only branch that nobody has tested.