Question: Assuming that feature flag toggles are a good idea, and should be implemented into code that developers write. For example Etsy swear by them as a [major part of their culture](https://codeascraft.com/2011/02/04/how-does-etsy-manage-development-and-operations/).

**What is a good way to persuade (and enforce) developers to start using feature flag toggles?**

More information about feature flag toggles is explained in [Q: How to use feature flag toggles](https://devops.stackexchange.com/questions/162/how-to-use-feature-flag-toggles), [Q: What are feature flag toggles](https://devops.stackexchange.com/questions/344/what-is-a-feature-flag-toggle-and-when-to-use-them-or-not) and very extensively in Pete Hodgson's [article on the subject on Martin Fowler's blog](https://martinfowler.com/articles/feature-toggles.html).

Answer: 
Feature toggles are a common practice in high-velocity development because they de-couple *development* from *release.* Dev teams can "soft-release" a new feature to production, in a disabled state. This allows the feature to be released any time. If the feature is dependent on other work or preparation, it doesn't have to wait for a major release to go to production.

As far as "convincing" developers to use them, that's an exercise in making the case for the freedom it offers. My experience is that it's not a tough sell to developers. It's management that tends to be reluctant to try new things. Try this:

* Find a feature toggle framework. Management/the business may be more
amenable to trying something supported by a common system
* Start small. Introduce the toggle system on a trial basis for a feature that will demonstrate its utility.
* Demonstrate the toggle's ability to do A/B testing. Enable the toggle for a subset of your web farm, then gather metrics on behavior. Tiny differences in page layout have been demonstrated to have huge effects on revenue for retail applications (e.g. Ebay, Amazon)
A successful high-velocity development environment typically relies on a pretty strict automated system involving quality verifications with detection and rejection of faulty changes causing regressions.

Feature toggles offer the ability to commit even work-in-progress, untested changes without getting rejected for causing regressions in the integration branch. Which constitues a very good **incentive** to introduce the feature toggles very early in the life of the feature.

One of the disadvantages of deviating from true CI and moving feature development on feature branches is the lack of such incentive. Adding the feature toggle later on, when merging the feature branch into the integration branch is typically more difficult, like any late integration.