> A **feature toggle** in [software development](https://en.wikipedia.org/wiki/Software_development "Software development") provides an alternative to maintaining multiple [feature branches](https://en.wikipedia.org/wiki/Branching_(version_control) "Branching (version control)") in [source code](https://en.wikipedia.org/wiki/Source_code "Source code"). A condition within the code enables or disables a [feature](https://en.wikipedia.org/wiki/Software_feature "Software feature") during [runtime](https://en.wikipedia.org/wiki/Runtime_(program_lifecycle_phase) "Runtime (program lifecycle phase)"). In agile settings the toggle is used in production, to switch on the feature on demand, for some or all the users. Thus, feature toggles do make it easier to [release](https://en.wikipedia.org/wiki/Software_release_life_cycle "Software release life cycle") often. Advanced roll out strategies such as canary roll out and [A/B testing](https://en.wikipedia.org/wiki/A/B_testing "A/B testing") are easier to handle. > A feature toggle is also called **feature switch**, **feature flag**, **feature gate**, **feature flipper**, **conditional feature**. Feature toggles are particularly useful for enabling regular merges to mainline in [[Continuous Integration]] workflows. ## Categories [^fn1] [^fn1]: [Feature flags in your codebase](https://zaidesanton.substack.com/p/feature-flags-are-ruining-your-codebase?triedRedirect=true) ##### 1. Release toggles  The one we started with - allows developers to merge non-ready code to production, turning it on once it’s ready. _Who is responsible for toggling it:_ Developers. Those types of toggles can exist in a configuration file.  _When should you delete it:_ A week or two after the release of the feature. ##### 2. Ops toggles Remember the resource-heavy feature we wanted to let our Ops team control?  > We might introduce an Ops Toggle when rolling out a new feature which has unclear performance implications so that system operators can disable or degrade that feature quickly in production if needed. _Who is responsible for toggling it:_ your Ops team - probably through a dedicated tool. _When should you delete it:_ 1-2 weeks**,** once you gain confidence in the new feature. In rare cases, you might keep some “Kill Switches”, to stop non-critical functionality when the system is under unusually high load.  ##### 3. Experiment toggles This type of toggle allows you to perform A/B testing. You divide the users into groups, each getting a different experience. While the toggle is active, you collect enough data to make the final decision.  _Who is responsible for toggling it:_ It varies, but mostly PMs.  _When should you delete it:_ a few days/weeks - once you get enough data to make a final decision.  ##### 4. Permission toggles I left the most dangerous for last. This type of toggle allows you to change the features and experiences specific users have on your website. It may be through having “premium” features for paying customers, or “alpha” / “beta” features, for internal users / beta customers.  This type is dangerous because it needs to be **very long-lived**, sometimes years. Treating it the same way as the other toggles, as something that will be deleted soon, is a critical and common mistake.  **Who is responsible for toggling it:** PMs **When should you delete it:** You will probably not be the one deleting it… Some poor developer will do it in a few years. --- ## References - https://en.wikipedia.org/wiki/Feature_toggle - https://zaidesanton.substack.com/p/feature-flags-are-ruining-your-codebase?triedRedirect=true