How to persuade developers to start using feature flag toggles?



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.


Posted 2017-03-05T12:02:52.467

Reputation: 7 247

1Oeps, 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 2017-03-05T13:27:49.470



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)

Dave Swersky

Posted 2017-03-05T12:02:52.467

Reputation: 3 573

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 2017-03-06T01:48:26.857

About the framework bit, there is an interesting OSS from Intuit called Wasabi

Evgeny 2017-03-06T03:28:09.003

Book recommendation on persuading other developers - Driving Technical Change by Terrence RyanLiath 2017-03-08T07:38:06.817


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.

No Refunds No Returns

Posted 2017-03-05T12:02:52.467

Reputation: 254


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.

Dan Cornilescu

Posted 2017-03-05T12:02:52.467

Reputation: 5 812


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

Stuart Ainsworth

Posted 2017-03-05T12:02:52.467

Reputation: 756


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.

Sudharsan S

Posted 2017-03-05T12:02:52.467

Reputation: 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 2019-04-13T13:58:13.103