Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Does your team use feature flags?

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 143 posts

Re: Ask HN: Does your team use feature flags?

#31

Post by symlinkk »

deminature wrote: post #30
aerovistae wrote: post #24

Extensively. Nearly every single change to the codebase is flagged. Even switching copy is behind a flag sometimes if the copy is across multiple places. I find it excessive and irritating; it feels like cargo cult programming to me.

It's risk mitigation. Feature flagging everything is a pointless waste of time until suddenly you have to roll something back in production and it's not feature flagged. The value of feature flags increases with the greater the cost of a mistake making it to production. For iOS builds particularly, that might have a 1-2 day review delay before you can get a new build approved, they're invaluable.

For iOS maybe, but for websites couldn’t you just revert the commit?

Re: Ask HN: Does your team use feature flags?

#32

Post by drclau »

Worked for a bigtech well known name, large and extremely important project, literally the core of a service serving an enormous number of users, and feature flags were mandatory, no exceptions.

I can't imagine working without feature flags. Being able to enable new features in particular deployment rings (canary, dogfood, various production rings or regions), or per users / user groups, enabling gradually (percentage) and so on, is invaluable. I really can't overstate this.

Heck, we went as far as using feature flags for risky bugfixes even.

We had also internal tools to easily work with and track feature flags. A downside is that although normally you'd want to remove old feature flags that become obsolete, this hasn't been done very often.

What I suggested and we started doing was to tag the feature flags with the name of the author and the date at which they were added, and the same for the config updates, and usually ticket number and title for both case. This did help with tracking obsolescence, but obviously there was still a need to plan and do the actual work. Automating this process further was out of the question, due to the high risks involved.

Edit: added the last paragraph.

Re: Ask HN: Does your team use feature flags?

#33

Post by phphphphp »

candiddevmike wrote: post #25

No, we do monthly releases instead and make sure they're stable or fix them with a follow up bug fix if they're not. If a feature isn't ready yet, it doesn't get into the release (or develop branch). I personally think feature flags are useful if you're deploying very frequently, but they just add confusion to software that's meant to be released/stable, especially for those developing it (what's with all the half do…

Feature flags aren't a gateway to half-done code and TODOs unless they're misused: all code should be production ready, whether it's behind a feature flag or not. A feature flag severs the relationship between the availability of a feature and its appearance in code, which is very useful for lots of reasons -- pushing half-baked code isn't one!

Re: Ask HN: Does your team use feature flags?

#34

Post by preordained »

Yes, we do, not in the way a lot of people are describing here (push without disruption, a/b testing). We deploy on prem applications that can be managed from the cloud, so when we add a new feature that involves said applications we have to observe which features the deployed application can use (til upgraded) and only display the appropriate ones from the cloud UI.

Re: Ask HN: Does your team use feature flags?

#35

Post by rozenmd »

dogleash wrote: post #23
tlongo wrote: post #16

Earlier quoted context omitted.

Drifting branches seems to be the main argument pro feature flags. I wonder how teams avoid breaking parts sleeping behind feature flags, by the ongoing development of its surroundings.

>I wonder how teams avoid breaking parts sleeping behind feature flags, by the ongoing development of its surroundings. Just duplicate the testing jobs with the feature flag flipped. Configure new job to turn expected-failure test cases into expected-pass (or whatever analogous way you keep track of it).

For my employer we write tests for both sides of the flag.

Re: Ask HN: Does your team use feature flags?

#36

Post by politelemon »

Not anymore. We do still have the ability. Some teams have found that it introduced an overhead (moving part, point of failure) and long lived staleness into certain parts of the codebase, which is actually reflective of our teams' priorities. Feature flags bring an overhead that teams should be aware of an acknowledge the management required, before introducing it into a tech stack.

Re: Ask HN: Does your team use feature flags?

#37

Post by aerovistae »

symlinkk wrote: post #31
deminature wrote: post #30

Earlier quoted context omitted.

It's risk mitigation. Feature flagging everything is a pointless waste of time until suddenly you have to roll something back in production and it's not feature flagged. The value of feature flags increases with the greater the cost of a mistake making it to production. For iOS builds particularly, that might have a 1-2 day review delay before you can get a new build approved, they're invaluable.

For iOS maybe, but for websites couldn’t you just revert the commit?

Exactly.

Re: Ask HN: Does your team use feature flags?

#38

Post by pfarrell »

symlinkk wrote: post #31
deminature wrote: post #30

Earlier quoted context omitted.

It's risk mitigation. Feature flagging everything is a pointless waste of time until suddenly you have to roll something back in production and it's not feature flagged. The value of feature flags increases with the greater the cost of a mistake making it to production. For iOS builds particularly, that might have a 1-2 day review delay before you can get a new build approved, they're invaluable.

For iOS maybe, but for websites couldn’t you just revert the commit?

There are other uses if your flagging system is not "all or nothing". They can be very useful if they support directing a subset of users, customers, or traffic to new code/infra. The bigger a team gets, the more value you get from this.

In fact, FF like this can be used for A/B testing too.

Re: Ask HN: Does your team use feature flags?

#39

Post by spookthesunset »

drclau wrote: post #32

Worked for a bigtech well known name, large and extremely important project, literally the core of a service serving an enormous number of users, and feature flags were mandatory, no exceptions. I can't imagine working without feature flags. Being able to enable new features in particular deployment rings (canary, dogfood, various production rings or regions), or per users / user groups, enabling gradually (percentag…

That is the one problem we’ve found with feature flags. It’s very easy to forget to gut the “old” parts when they are turned off. In many cases I’ve seen two or three year-old feature flags whose stale end still remains because the developer and / or team that did the branch never cleaned up. It isn’t usually malicious or lazy… it’s just how things would pan out.

Then we’d be nervous removing the old stuff cause who knows why it was left there and who knows if they’d want it back on again…

Re: Ask HN: Does your team use feature flags?

#40

Post by bschne »

drclau wrote: post #32

Worked for a bigtech well known name, large and extremely important project, literally the core of a service serving an enormous number of users, and feature flags were mandatory, no exceptions. I can't imagine working without feature flags. Being able to enable new features in particular deployment rings (canary, dogfood, various production rings or regions), or per users / user groups, enabling gradually (percentag…

> A downside is that although normally you'd want to remove old feature flags that become obsolete, this hasn't been done very often.

I figure this should be somewhat automatable since the relevant bits of code have references to the exact flag's identifier. Was it not done b/c nobody was incentivized in any way to spend any kind of time on cleanup?

edit: OK that might be a bit naive on the organizational side. Force everyone to give every flag an expiry date for review or something maybe?

Post reply on HN