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

81–90 of 143 posts

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

#81

Post by the_gipsy »

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…

> What I suggested and we started doing was to tag the feature flags with the name of the author

I suggest tagging the PO/manager who requested the feature.

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

#82

Post by pkaeding »

spookthesunset wrote: post #39
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…

I have found it can be good to 'remove' the flag at the same time you create it, but just don't merge the removal until later. I wrote up this idea in a blog post a while ago, if anyone finds it interesting: https://launchdarkly.com/blog/how-to-use-feature-flags-witho...

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

#83

Post by spookthesunset »

obstacle1 wrote: post #80
spookthesunset wrote: post #39

Earlier quoted context omitted.

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…

That's not a problem with feature flags per se, it's a problem with lazy implementations of feature flags. Flags should be associated with an expiry date, and company comms tooling should be consistently yelling in some public channel when expired flags still exist in the codebase.

> That's not a problem with feature flags per se, it's a problem with lazy implementations of feature flags.

Oh absolutely. Feature flags are great, but you definitely need discipline to make sure you clean things up. The longer the unused code rots, the harder it is to remove it.

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

#84

Post by yojo »

nicoburns wrote: post #71
yojo wrote: post #53

Earlier quoted context omitted.

This exactly. Feature flags are necessary for rollouts, but they also quickly become technical debt. Multiple outages happened at my last company when the feature flag service went down and old flags defaulted to “off”. It got to the point that the supporting team restricted flag-based rollouts to 95%. If you wanted it on for everyone, you had to remove the flag. Not sure if I fully agree with that design, but as an…

Sounds like you have too many services if you have one just for feature flags! At my company we bundle feature flagging into the main auth service, if you can login then you can access your feature flags.

The feature flag service was doing double duty as both the “marketing experimentation A/B testing” platform and the “feature rollout” platform. Not defending the service boundaries, but it had enough meat by itself that there was a full time team working on it.

I also think the intent of the service was to be used for temporary experiments and rollouts, with the assumption that everything in the system could safely turn off. If these assumptions held you might not want to allow a bug in the flag service to take down auth. Indeed, the outages we did have from feature flag service going down would have been worse outages if it was crashing all of auth and unaffected clients couldn’t log in.

In practice long running tech debt resulted in unexercised code paths that might be years out of date.

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

#85

Post by SkyPuncher »

We simply have a column on a few our of models called "features". Just an array with plaintext values. It's just branching logic on the FE/BE.

The biggest thing with feature flags is using them at an appropriate level of granularity for the stage of company you're at. Branching logic adds complexity.

Consider starting with an entire feature/route/page set to keep the branching logic consolidated and simple. Only move to more granularity as you need it.

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

#87

Post by yojo »

ford wrote: post #55
yojo wrote: post #53

Earlier quoted context omitted.

This exactly. Feature flags are necessary for rollouts, but they also quickly become technical debt. Multiple outages happened at my last company when the feature flag service went down and old flags defaulted to “off”. It got to the point that the supporting team restricted flag-based rollouts to 95%. If you wanted it on for everyone, you had to remove the flag. Not sure if I fully agree with that design, but as an…

It sounds like a poor design choice to not give clients the ability to set their own defaults

Config level defaults were set in the flag service. But when that goes down, the client has to decide what to do.

I think there was an optional arg for specifying default behavior, but even when used there’s the problem that the default you pick for a rollout will be “off”. If you don’t go back and change it later, you’re back in the same boat.

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

#88

Post by bob1029 »

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.

We use feature flags a ton and this is something that burns us a little bit too.

The upsides are worth it though. Having that surgical precision in production is essential when you have a complex product that touches many lines of business.

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

#90

Post by willcipriano »

ford wrote: post #58

A different question - how do teams that don't use feature flags accomplish the things feature flags enable? Namely: 1) Validating you can handle production-scale 2) Ensuring integrations/environment-related issues don't happen when you deploy 3) Alpha/Beta groups of users 4) Quick reversions when something does not work as expected Similar to other commenters I can't imagine not using feature flags. Some of these mi…

I like the idea of feature flags and implement that pattern into my code from time to time, however I've never worked on a team that uses them. This is how they do it instead:

> 1) Validating you can handle production-scale

I've never seen anyone actually do this. Lots of people expect AWS to handle the heavy lifting here.

> 2) Ensuring integrations/environment-related issues don't happen when you deploy

Deployment to the test or staging env.

> 3) Alpha/Beta groups of users

Most often some sort of user permission system. Sometimes they run two nodes and have both run different versions of the software.

> 4) Quick reversions when something does not work as expected

A deployment. How long that takes depends on how the software is architected, but 5 - 10 minutes isn't uncommon.

Post reply on HN