<p>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.</p>

<p>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 <strong>incentive</strong> to introduce the feature toggles very early in the life of the feature.</p>

<p>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.</p>

CC BY-SA 3.0
2017-03-06T05:10:43.287Z
2017-03-06T05:10:43.287Z
Dan Cornilescu
<p>Developers (and usually development managers) usually look for two outcomes associated with framework: ease of management, and speed of deployment.  You want to ship code faster, and easier.</p>

<p>Provide evidence that the approach works; try building a small POC using feature flags versus the old way.  Case studies matter less to tactical people (developers\engineers) than strategic people (middle management\product designers).</p>

CC BY-SA 3.0
2017-09-26T11:33:36.530Z
2017-09-26T11:33:36.530Z
Stuart Ainsworth
<p>In an ideal world I think you roll out a new build and surprise! NOTHING changes.  This is because all of your new features are behind switches that go out with the switch off.</p>

<p>Post-deployment you verify that your rolled-out service still works, the phones aren't ringing any more (unless ringing phones is your purpose, that is), etc.  Once you are back to a known stable operation you begin enabling and verifying your newly deployed features.</p>

<p>Now for your answer:  How would you like to work on a team where being on call is practically a no-brainer and our users love us because our sites and services are rock solid stable?</p>

<p>That's the team I want to work on.</p>

<p>You can stop reading here if you want.</p>

<p>Putting everything behind a feature switch seems like it can lead to spaghetti code everywhere.  If you use IoC and are able to select between vNow/vNext/vPrevious then it comes down to maintaining your configuration.  Yes more check ins, yes more classes (componentV1, componentV2, componentV3, etc.) but you actually have a more stable system?  How?  vNext is wonky?  Switch back to vNow with your control tower.  Been a week and vNow has a subtle bug?  Same thing - go back to vPrevious just as easily.</p>

<p>No hassle, no worries, no lost sleep, no stress.</p>

<p>This isn't a pipe dream.  I used to work there.  Wish I could sell this to my current team.</p>

CC BY-SA 3.0
2017-03-07T04:34:08.570Z
2017-03-08T04:43:29.210Z
2017-03-08T04:43:29.210Z
No Refunds No Returns
<p>The rationale to have feature toggles is not something for developers to decide. This is something for product owners to care. Developers enable this change in the most sustainable and safe manner. I critique this very question.</p>

CC BY-SA 4.0
2019-04-13T13:58:13.103Z
I've been in organizations where the developers are the product owners.  I've seen product management act like product owners a few times.  And I've been places where nobody seems to own anything.  So your statement fits with roughly a third of my experience.  Encouraging the developers to write things in a way that will work better in production seems like a generally good thing to me.  Can you cite any authorities to support your view?
chicks
CC BY-SA 4.0
2019-04-11T07:54:38.460Z
2019-04-11T07:54:38.460Z
Sudharsan S
<p>Feature toggles are a common practice in high-velocity development because they de-couple <em>development</em> from <em>release.</em>  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.</p>

<p>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:</p>

<ul>
<li>Find a feature toggle framework.  Management/the business may be more
amenable to trying something supported by a common system</li>
<li>Start small.  Introduce the toggle system on a trial basis for a feature that will demonstrate its utility.</li>
<li>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)</li>
</ul>

CC BY-SA 3.0
2017-03-06T03:28:09.003Z
About the framework bit, there is an interesting OSS from Intuit called Wasabi https://github.com/intuit/wasabi
Evgeny Zislis
CC BY-SA 3.0
2017-03-08T07:38:06.817Z
Book recommendation on persuading other developers - Driving Technical Change by Terrence Ryan
Liath
CC BY-SA 3.0
2017-03-06T01:48:26.857Z
+1 for the framework bit. I've seen too many people roll their own feature toggles and it's always nasty, nasty code.
Jduv
CC BY-SA 3.0
2017-03-05T12:11:56.213Z
2017-03-05T12:11:56.213Z
Dave Swersky
<p>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 <a href="https://codeascraft.com/2011/02/04/how-does-etsy-manage-development-and-operations/" rel="noreferrer">major part of their culture</a>.</p>

<p><strong>What is a good way to persuade (and enforce) developers to start using feature flag toggles?</strong></p>

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

CC BY-SA 3.0
2017-03-05T12:03:05.933Z
A narrow version for the http://devops.stackexchange.com/questions/4/how-to-change-existing-policies-in-an-organisation question.
Evgeny Zislis
CC BY-SA 3.0
2017-03-05T13:27:49.470Z
Oeps, I only now see you new comment (and update). After I just posted a new question about them. Maybe you want to post an answer to my new question (where you have way more space to actually explain these thingies)? If you do, make sure it is not a link-only answer (I trust you know what that means on SE sites, right?).
Pierre.Vriens
<culture><feature-flags><transformation>
How to persuade developers to start using feature flag toggles?
Evgeny Zislis
# How to persuade developers to start using feature flag toggles?

(Asked by: username_0 on 2017-03-05)

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).

**Tags:** culture, feature-flags, transformation

> **Comments:**
> **username_0**: A narrow version for the http://devops.stackexchange.com/questions/4/how-to-change-existing-policies-in-an-organisation question.  
> **username_1**: Oeps, I only now see you new comment (and update). After I just posted a new question about them. Maybe you want to post an answer to my new question (where you have way more space to actually explain these thingies)? If you do, make sure it is not a link-only answer (I trust you know what that means on SE sites, right?).  

---

## 5 answers

### Answer by username_7 on 2017-03-05. Score: 18 | Accepted 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)

> **Comments:**
> **username_9**: +1 for the framework bit. I've seen too many people roll their own feature toggles and it's always nasty, nasty code.  
> **username_0**: About the framework bit, there is an interesting OSS from Intuit called Wasabi https://github.com/intuit/wasabi  
> **username_8**: Book recommendation on persuading other developers - Driving Technical Change by Terrence Ryan  

---

### Answer by username_4 on 2017-03-07. Score: 8

In an ideal world I think you roll out a new build and surprise! NOTHING changes. This is because all of your new features are behind switches that go out with the switch off.

Post-deployment you verify that your rolled-out service still works, the phones aren't ringing any more (unless ringing phones is your purpose, that is), etc. Once you are back to a known stable operation you begin enabling and verifying your newly deployed features.

Now for your answer: How would you like to work on a team where being on call is practically a no-brainer and our users love us because our sites and services are rock solid stable?

That's the team I want to work on.

You can stop reading here if you want.

Putting everything behind a feature switch seems like it can lead to spaghetti code everywhere. If you use IoC and are able to select between vNow/vNext/vPrevious then it comes down to maintaining your configuration. Yes more check ins, yes more classes (componentV1, componentV2, componentV3, etc.) but you actually have a more stable system? How? vNext is wonky? Switch back to vNow with your control tower. Been a week and vNow has a subtle bug? Same thing - go back to vPrevious just as easily.

No hassle, no worries, no lost sleep, no stress.

This isn't a pipe dream. I used to work there. Wish I could sell this to my current team.


---

### Answer by username_2 on 2017-03-06. Score: 4

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.


---

### Answer by username_3 on 2017-09-26. Score: 2

Developers (and usually development managers) usually look for two outcomes associated with framework: ease of management, and speed of deployment. You want to ship code faster, and easier.

Provide evidence that the approach works; try building a small POC using feature flags versus the old way. Case studies matter less to tactical people (developers\engineers) than strategic people (middle management\product designers).


---

### Answer by username_5 on 2019-04-11. Score: 0

The rationale to have feature toggles is not something for developers to decide. This is something for product owners to care. Developers enable this change in the most sustainable and safe manner. I critique this very question.

> **Comments:**
> **username_6**: I've been in organizations where the developers are the product owners.  I've seen product management act like product owners a few times.  And I've been places where nobody seems to own anything.  So your statement fits with roughly a third of my experience.  Encouraging the developers to write things in a way that will work better in production seems like a generally good thing to me.  Can you cite any authorities to support your view?  

---

