5 exercises — Practice feature flag vocabulary in English: kill switch, rollout percentage, targeting rules, flag lifecycle management, LaunchDarkly, and OpenFeature standards.
A product manager explains the release strategy to a new engineer: "We use feature flags for every significant feature. The code ships to production but the feature is off by default — controlled by a flag. When we're ready, we don't do a big-bang release. We enable it for internal users first, then 1% of users, then 10%, then 50%, then 100%. If metrics degrade at any rollout percentage, we turn the flag off instantly — no deployment needed. That instant off switch is what makes flags powerful for risk management. We call it a kill switch." What is a kill switch in the context of feature flags?
Kill switch (ops toggle): a feature flag specifically designed as a circuit breaker for operational risk. Unlike release toggles (enabling new features gradually), ops toggles are permanent fixtures — they exist to provide rapid response capability indefinitely. Examples: a flag to disable a new payment integration if the third-party service goes down; a flag to switch from a new recommendation algorithm back to the old one if CTR drops; a flag to disable a resource-intensive feature during peak traffic. Feature flag taxonomy (Martin Fowler): Release toggle: hides incomplete features, enables trunk-based development. Short-lived — removed after graduation. Experiment toggle: A/B testing, multivariate experiments. Controls which variant a user sees. Ops toggle: kill switch, performance toggle. Longer-lived, sometimes permanent. Permission toggle: enables features for specific user segments (beta users, paying customers, internal staff). Rollout vocabulary: Percentage rollout: enable for a random percentage of users (e.g., 5%). Targeting rule: enable for users matching criteria (country, plan, email domain, user ID). Default rule: fallback for users not matching any targeting rule. Gradual rollout: progressively increase the percentage over time, monitoring metrics at each step. In conversation: 'Every significant production deployment should have a kill switch. The two minutes it takes to add a flag beats the hour of emergency deployment to revert.'
2 / 5
A senior engineer explains how they use feature flags for A/B testing: "We're testing two versions of our checkout flow. Flag 'new-checkout-v2' has a targeting rule: 50% of users get variant 'new', 50% get 'control'. The assignment is sticky — the same user always gets the same variant, based on their user ID. We measure conversion rate, cart abandonment, and revenue per session. The experiment runs for two weeks to get statistical significance. LaunchDarkly's SDK evaluates the flag client-side so there's no server round-trip on each page render." What does sticky assignment mean in feature flag experiments?
Sticky assignment: a user must always see the same variant for an experiment to be valid. If a user saw "new checkout" on Monday and "control" on Wednesday, their behavior data is polluted — you can't attribute their conversion to either variant. Implementation: hash(userID + flagKey) → modulo percentage boundary. Same inputs always produce the same output, so assignment is deterministic without storing per-user state. A/B testing vocabulary: Control: the existing behavior (baseline). Variant/Treatment: the new behavior being tested. Allocation: the percentage assigned to each variant. Statistical significance: confidence that observed differences are not random noise (typically p < 0.05). Minimum detectable effect (MDE): the smallest improvement the experiment is powered to detect. Sample ratio mismatch (SRM): when actual traffic split differs from intended — a sign of a broken experiment. LaunchDarkly concepts: Flag variation: possible values (true/false for boolean, or strings/JSON for multivariate). Targeting rules: ordered rules — first match wins. If no rule matches, the default rule applies. Contexts: multi-context SDK — evaluate flags based on user, organization, device, or any custom entity. Streaming connection: SDK maintains SSE/websocket connection to LD; flag changes propagate in milliseconds. In conversation: 'If your experiment doesn't use sticky assignment, your results are meaningless. A user seeing both variants introduces noise that inflates variance and can mask real effects.'
3 / 5
A tech lead raises a concern in a quarterly code review: "We have 47 feature flags in this codebase. Twelve of them have been fully rolled out to 100% of users for more than six months. But the flag checks are still in the code. The engineers who added them left the company. Nobody knows if it's safe to remove them. This is flag debt — stale flags that add cognitive overhead, make the code harder to understand, and create untested code paths. Every flag should have an owner, a removal date, and a process for cleanup after graduation." What is flag debt and what causes it?
Flag debt: a form of technical debt specific to feature management. A flag passes through a lifecycle: Create → Evaluate in test → Gradual rollout → 100% → Graduate (flag removed). The "graduate" step is where teams fail. Consequences of stale flags: Dead code paths: the "false" branch of a fully-rolled-out flag is dead code — never executed, never tested. Cognitive overhead: every developer reading the code must parse "what does this flag do, is it on or off?". Testing complexity: each flag doubles the number of code paths to test. N flags = 2^N theoretical paths. Flag evaluation failures: if the flag platform is down and you have no cached defaults, old code paths may behave unexpectedly. Flag lifecycle best practices: Owner: assign an engineer responsible for cleanup. Expiry date: document expected removal date when creating the flag. Graduation criteria: define what "100% rollout and stable" means. Removal PR: when graduating, create a dedicated PR that removes the flag check and the dead code branch. Tests: remove flag-specific test variants and ensure coverage of the now-permanent behavior. OpenFeature vocabulary: an open standard (CNCF) for feature flag SDKs — vendor-neutral API that providers implement. Allows switching between LaunchDarkly, Unleash, Flagsmith, etc. without changing application code. In conversation: 'Treat flag removal like bug fixes — it improves code health. Schedule it in the same sprint as the 100% rollout, not "someday".'
4 / 5
A product engineer presents the team's progressive delivery strategy: "We practice continuous deployment — code goes to production multiple times a day. But 'deployed' doesn't mean 'released'. New features are deployed behind flags and dark-launched: they execute in production but the user never sees the output. We measure performance, error rates, and resource usage. If everything looks good, we start the rollout: 1% → 5% → 25% → 100%. At each step we gate on metrics — error rate below 0.1%, p99 latency under 200ms. If a metric breaches, we pause. This is progressive delivery." What is progressive delivery and how does it differ from continuous delivery?
Progressive delivery: coined by James Governor (RedMonk). Continuous delivery gets code to production reliably; progressive delivery controls how that code reaches users. Decouples deployment (technical operation) from release (business decision). Techniques: Feature flags: code is deployed to all servers but user-visible only to a percentage. Canary release: deploy new version to a small subset of servers; route a percentage of traffic to them. Unlike flags, canaries involve multiple active code versions running simultaneously. Blue-green deployment: full environment switch with instant rollback. Dark launch: execute new code path but discard output — test performance and correctness in production with no user impact. A/B testing: compare two variants with statistical rigor. Ring-based deployment: deploy in concentric rings — internal, beta, production east, production global. Metric gates: automated promotion decisions based on error rate, latency, business metrics. Tools like Argo Rollouts and Flagger automate canary analysis. OpenFeature standard: defines a vendor-neutral SDK interface for flag evaluation. Application code calls OpenFeature API; a provider plugin connects to LaunchDarkly, Unleash, etc. Allows migration between providers without code changes. In conversation: 'Deploy and release are different words with different meanings. Separating them with flags is one of the highest-leverage practices in modern software delivery.'
5 / 5
An engineering manager explains the team's trunk-based development workflow: "All engineers commit directly to the main branch — no long-lived feature branches. But features take weeks to build. The solution: wrap incomplete features in a flag. The flag is off by default. Engineers commit their work-in-progress daily. CI runs against main, everything passes because the new code path is never reached. Once the feature is complete, we enable the flag in staging, then gradually in production. This is how flags enable trunk-based development — incomplete code ships safely because flags prevent users from reaching it." How do feature flags enable trunk-based development?
Trunk-based development (TBD): all developers integrate to a single main branch (trunk) at least once a day. Avoids long-lived feature branches, which cause painful merge conflicts and delay integration feedback. The challenge: a feature taking 3 weeks cannot be committed piecemeal to main without exposing incomplete work to users. Feature flags solve this: The flag is created first, defaulted to off. All feature code is wrapped in the flag check (if (flags.isEnabled('new-search'))). Daily commits to main — CI passes because the flag is off in all environments. Flag enabled in dev/staging when feature is testable. Gradual production rollout when ready. Flag removed after graduation. Benefits: no merge conflicts from long-lived branches; CI always runs against the integration point; the main branch is always deployable; collaboration is easier when everyone works on the same branch. Complementary practices: Feature branches: still used, but for hours/days, not weeks. Branch by abstraction: for large-scale refactoring without flags. Code-level patterns for flags: Decision point: the place in code where the flag is evaluated. Flag router: single class/module that encapsulates all flag evaluations. Avoids scattering SDK calls. Branching by abstraction: use an interface/adapter pattern to swap implementations. In conversation: 'The best feature branch is one that lives for less than a day. Flags make that possible for features that take weeks to build.'