English for Feature Flag Platform Developers

Feature flag platforms let teams decouple deployment from release, but that flexibility comes with vocabulary a team needs to share precisely — a “rollout,” a “kill switch,” and an “experiment” are three different things with three different risk profiles, and confusing them in a discussion can lead to the wrong safety precautions being taken. This guide covers the English used when discussing feature flag platforms with a team.

Key Vocabulary

Targeting rule — a condition (based on user attributes like plan tier, region, or user ID) that determines which users see which variation of a flag, evaluated on every flag check. “The bug only affected enterprise customers because the targeting rule was scoped to the plan:enterprise attribute — everyone else was on the old code path the whole time.”

Percentage rollout — gradually increasing the share of users who receive a new flag variation, typically to catch problems on a small population before a full release. “Don’t jump straight to 100% — start this at a 5% rollout and watch error rates for an hour before increasing it.”

Kill switch — a flag whose sole purpose is to disable a feature or code path instantly in production without a deploy, used as an operational safety mechanism rather than a release mechanism. “Wrap the new payment retry logic in a kill switch — if it misbehaves under real load, we need to be able to turn it off in seconds, not wait for a rollback deploy.”

Flag debt — the accumulation of old feature flags left in the codebase long after their rollout is complete, adding complexity and risk with no ongoing benefit. “This flag has been at 100% for eight months and every user is on the new path — that’s flag debt, let’s remove the flag and the old code path entirely.”

Stickiness — the guarantee that a given user consistently gets the same flag variation across sessions, usually achieved by hashing a stable user identifier, so users don’t flicker between experiences. “Users were seeing the new checkout flow on one visit and the old one on the next — that’s a stickiness bug, the flag’s bucketing key isn’t stable across sessions.”

A/B test (experiment) flag — a flag used specifically to randomly assign users to variations for statistical comparison, distinct from a simple rollout flag, and usually tied to an analytics or experimentation platform. “This isn’t a rollout flag, it’s an experiment flag — don’t manually override anyone’s assignment, or you’ll bias the statistical results we’re trying to measure.”

Common Phrases

• “Is this a kill switch, a rollout flag, or an experiment flag — because the safety expectations are different for each?”
• “What’s the current rollout percentage, and what’s the plan for increasing it?”
• “Is this flag still needed, or is it flag debt we should clean up?”
• “Is this user’s assignment sticky across sessions, or could it flicker?”
• “Is anyone manually overriding assignment on this experiment flag?”

Example Sentences

Reviewing a pull request: “This flag has been fully rolled out for months with no plan to remove it — let’s add a ticket to delete the flag and the fallback code path, this is flag debt.”

Explaining a design decision: “We wrapped the new recommendation algorithm in a kill switch separate from its rollout flag, so ops can disable it instantly during an incident without touching the rollout percentage.”

Describing a bug: “Users kept flip-flopping between the old and new UI because the flag was bucketing on session ID instead of user ID — switching to a stable user-based key fixed the stickiness issue.”

Professional Tips

• Say “kill switch” specifically for an emergency-disable flag — using “flag” generically for both rollout and kill-switch purposes muddies the operational risk conversation.
• When reviewing flag usage, ask “is this flag debt?” — a flag stuck at 100% or 0% with no active purpose should trigger a cleanup ticket, not be left indefinitely.
• Use “stickiness” precisely when describing consistent per-user assignment — it’s the standard term and distinguishes the concern from targeting rules or rollout percentage.
• Distinguish an “experiment flag” (statistical assignment, don’t manually override) from a “rollout flag” (progressive release, manual overrides for support cases are often fine) when setting expectations with support teams.

Practice Exercise

1. Explain in two sentences the difference between a kill switch and a percentage rollout.
2. Write a one-sentence code review comment flagging an old flag as flag debt.
3. Describe, in your own words, why manually overriding a user’s assignment on an experiment flag is a problem.

Navigating Nuance: Common Phrasing Pitfalls & Best Practices

Let’s be honest – learning professional English as a developer can feel overwhelming. It’s not just about knowing the definitions of words; it’s about understanding how they’re used in context, particularly when discussing technical details like feature flags. Many common phrases sound awkward or imprecise if delivered without a solid grasp of their nuances. For example, simply stating “we’ll roll out 80%” can be misinterpreted – what does ‘roll out’ really mean? It might imply a single, monolithic deployment, rather than a gradual, targeted release.

A frequent issue arises in code review comments. Imagine receiving this: “This flag isn’t working correctly.” While technically accurate, it lacks crucial context. A more helpful response, geared towards clearer communication, would be something like, “Can you clarify which user segment is affected by the flag and what the expected behavior is? Is there a specific error message being logged when the flag is inactive?” Notice the added questions – they prompt for specific information needed to diagnose the problem effectively. Similarly, in Slack conversations discussing PRs, avoiding vague statements like “The feature flag needs fixing” and instead opting for “I’m seeing inconsistent behavior with this flag targeting users in the beta group; could we investigate why it’s not activating as expected?” demonstrates a more professional and actionable approach.

Another area where confusion can easily arise is when discussing rollout percentages. Saying “we’ll roll out 20% to production” doesn’t automatically convey how that rollout will occur. Will it be linear? Exponential? Will there be any monitoring or feedback loops built in? It’s vital to specify the strategy. For instance, a good PR description might read: “We’ll gradually increase the flag exposure from 5% to 20% over the next 72 hours, monitored closely for performance impact and user feedback.” This level of detail ensures everyone understands the intended process.

Finally, remember that technical jargon is often layered with specific phrasing related to risk mitigation. Phrases like “reduce blast radius,” “controlled rollout,” or “surgical deployment” are frequently used when discussing feature flag implementations – they all point towards a deliberate strategy for managing potential negative consequences. Understanding these terms and how they’re applied in real-world scenarios will significantly improve your communication and collaboration with your team.

# Example: Using Unleash to query the status of a flag
unleash list --target "my_feature"