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.

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, Q: What are feature flag toggles and very extensively in Pete Hodgson's article on the subject on Martin Fowler's blog.

  • A narrow version for the devops.stackexchange.com/questions/4/… question. Commented Mar 5, 2017 at 12:03
  • 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?).
    – Pierre.Vriens
    Commented Mar 5, 2017 at 13:27

5 Answers 5


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)
  • 2
    +1 for the framework bit. I've seen too many people roll their own feature toggles and it's always nasty, nasty code.
    – Jduv
    Commented Mar 6, 2017 at 1:48
  • About the framework bit, there is an interesting OSS from Intuit called Wasabi github.com/intuit/wasabi Commented Mar 6, 2017 at 3:28
  • Book recommendation on persuading other developers - Driving Technical Change by Terrence Ryan
    – Liath
    Commented Mar 8, 2017 at 7:38

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.


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.


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


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.

  • 1
    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
    Commented Apr 13, 2019 at 13:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.