English for LaunchDarkly Feature Flags

Feature flags let you decouple deploying code from releasing it, but that only works well as a team practice if everyone uses the same vocabulary for targeting, variations, and rollback — otherwise “turn off the flag” can mean five different things depending on who says it.

Key Vocabulary

Flag variation — one of the possible values a flag can serve (often true/false, but can be a string, number, or JSON object), evaluated per request based on targeting rules. “This isn’t a simple on/off flag — it has three variations controlling which of three checkout layouts a user sees.”

Targeting rule — a condition (based on user attributes like plan tier, region, or a percentage rollout) that determines which variation a specific user or request receives. “We added a targeting rule serving the new variation only to users on the enterprise plan in the EU, so we can validate it with a controlled audience first.”

Percentage rollout — a targeting rule that distributes traffic across variations by percentage rather than by explicit attribute, used to gradually expand exposure to a new feature. “We’re at a 25% rollout right now — if error rates stay flat for another day, we’ll bump it to 50% and keep watching before going to 100%.”

Kill switch — a flag (or a flag’s off-state) used specifically as an emergency mechanism to instantly disable a feature in production without a code deploy or rollback. “We flipped the kill switch the moment the new payment provider started erroring — that took thirty seconds, versus the ten minutes a full rollback would have needed.”

Prerequisite flag — a flag configured to depend on another flag’s state, so its own targeting rules only take effect if the prerequisite flag is also serving a specific variation. “The new dashboard flag has the redesigned nav flag as a prerequisite — it doesn’t make sense to enable one without the other, so we enforced that dependency directly in the flag config.”

Common Phrases

• “How many variations does this flag have, and what determines which one a user gets?”
• “Is this targeting rule based on a user attribute, or a percentage rollout?”
• “What percentage are we at right now, and what’s the plan for ramping up?”
• “Is there a kill switch for this feature if something goes wrong after full rollout?”
• “Does this flag have a prerequisite, or can it be toggled independently?”

Example Sentences

Proposing a rollout plan in a design doc: “We’ll start at a 5% percentage rollout targeting only internal accounts, expand to 25% of all users after 24 hours of clean metrics, then go to 100% — with a kill switch ready at every stage.”

Explaining a targeting decision in review: “This targeting rule only serves the new variation to users with more than ten projects, since that’s the segment most likely to hit the performance issue we’re fixing.”

Responding during an incident: “Flipping the kill switch now — that reverts everyone to the old variation immediately, buys us time to debug without users seeing the broken behavior.”

Professional Tips

• Name the flag variation explicitly when reporting a bug tied to a flag — “the new feature is broken” is far less useful than “variation B of the checkout flag is failing for EU users.”
• State the targeting rule logic plainly when proposing a rollout — “we’ll turn it on for some people” invites confusion; “25% random rollout, no attribute targeting” doesn’t.
• Always confirm a kill switch exists and is tested before a risky flag goes to 100% — discovering there’s no fast way to disable a broken feature mid-incident is a bad time to learn that.
• Track percentage rollout stages and their exit criteria in the rollout plan itself — “we’ll expand it later” without a stated threshold tends to stall indefinitely at whatever percentage feels comfortable.

Practice Exercise

1. Write a sentence explaining the difference between a targeting rule and a percentage rollout.
2. Describe a kill switch scenario and why speed matters there.
3. Explain what a prerequisite flag is in your own words.

Navigating Nuance: Feature Flag Discussions in Team Communication

Let’s be honest – even with a solid understanding of targeting rules and variations, communicating effectively about LaunchDarkly feature flags can become tricky. The language itself is precise, but translating that precision into natural conversation, especially when collaborating across teams or explaining decisions to stakeholders who aren’t deeply technical, requires careful phrasing. It’s not just about stating facts; it’s about conveying intent and ensuring everyone understands the implications.

One common challenge arises during code reviews. Imagine receiving a comment on a pull request that implements a new feature flag variation: “This looks good, but can you elaborate on the rollout strategy? Specifically, why are we using this particular variation versus the default?” A direct translation of “What’s the rationale behind this targeting rule?” might feel overly formal and potentially intimidating. Instead, a more approachable phrasing would be: “Just to clarify – I see we’re introducing this variant for [briefly state intended use case]. Could you walk me through the logic driving this decision? It helps me understand how it integrates with the overall feature rollout.” Similarly, if explaining a kill switch implementation, saying “We’re disabling this feature” is too blunt. Instead, “We’ve implemented a kill switch to immediately halt the rollout of this variation in case we observe unexpected issues” sounds more professional and highlights the proactive risk mitigation.

Another area where nuance matters significantly is Slack conversations. A developer might send a message: “Deploying the ‘beta’ flag with a 20% audience.” A non-native speaker could immediately interpret that as simply a percentage of users. However, it’s crucial to understand that “20%” refers to the initial rollout – meaning 20% of the total user base would be exposed to the new variation initially. A more explicit phrasing might be: “Deploying the ‘beta’ flag with an initial audience of 20%, allowing us to monitor performance before a wider release.” This emphasizes the controlled and monitored nature of the rollout, which is key to successful feature flag implementation.

Finally, when writing PR descriptions, avoid jargon. Instead of saying “We’re utilizing dynamic targeting,” try “This PR introduces a new feature flag variation that allows us to test this functionality with a small subset of users before releasing it broadly.” This clarity helps ensure everyone – from the QA team to marketing – understands what’s happening and why.

launchdarkly flags create --name myFlag --variation myVariation --target-segment "user_id:12345" --environment production

This simple command demonstrates how LaunchDarkly allows you to precisely define a targeting rule based on user attributes, which is a core concept when discussing feature flag strategies. It’s a foundational element in conversations about controlling feature access and monitoring performance.