Ask HN: Does your team use feature flags? • Hacker News Board

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

#101

Post by bredren » Fri, Jan 28, 2022, 7:10 PM UTC

dpark wrote: post #67

bredren wrote: post #50

Earlier quoted context omitted.

How do you sync the state of production feature flag toggles, and FF config for developer environment or for standing up a new developer environment? For example, a new full-stack SWE is onboarding and has an env representing production, populated with test data. That engineer wants to run the product as it currently exists on production including the state of feature flags. How does this developer update this state,…

Build a service/loop/CI/cron job/whatever to pull feature flag state from prod and check into your relevant branch(es). Make the dev deployment apply this state by default. You’ll get a lot of extra value out of this if you have an automated test pass that exercises the bulk of the product. You get bonus points if you can integrate individual feature flags back to your branch(es) independently, because it will let yo…

This makes sense, thanks for this set of ideas.

Have you implemented this, or seen write-ups of this pattern described at length? Or perhaps commercial products providing for this scenario?

Curious about prior art on this subject.

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

#102

Post by GnarfGnarf » Fri, Jan 28, 2022, 7:13 PM UTC

I use them in my desktop software. They are invaluable in helping transition to new features without sitting on the code and waiting weeks to merge, or forking the code which comes with its own set of headaches and problems.

They allow us to work on new code in the debug version, while insuring stability and continuity in the production code.

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

#103

Post by ruh-roh » Fri, Jan 28, 2022, 7:20 PM UTC

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…

Starting new at a startup-with-traction several years ago, I had reason to check out the feature flag configs for my first feature. It was hilarious.

- There were hundreds of them, some of them going back to the garage days, multiple years old. Some would turn on/off major functionality core to the product. For example, this was an ecommerce product - one toggle was "show/hide the buy button". (I think that one is staying in.) - This was all hand-rolled, pre-LaunchDarkly stuff, but at least they were all in one place. I diffed Production, Staging, and a one-off UAT environment - the toggles were MASSIVELY different across each.

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

#104

Post by nicoburns » Fri, Jan 28, 2022, 7:21 PM UTC

yojo wrote: post #84

nicoburns wrote: post #71

Earlier quoted context omitted.

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 t…

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

Ah, we're small enough that we don't have a marketing team and we don't have capacity to do A/B testing either!

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

#105

Post by xcambar » Fri, Jan 28, 2022, 7:26 PM UTC

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?

That is a simplistic answer.

In a CD setup without feature flash, commit equals deploy equals launch. With feature flags, commit equals deploy. Launch is controlled by feature flags.

For a more mundane analogy, would you rather have a stove that allows cold or burning only, or one with every possible nuance of warm in between?

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

#106

Post by jaywalk » Fri, Jan 28, 2022, 7:43 PM UTC

dboreham wrote: post #89

Yes. But you don't need a SaaS service for this: it's just a field in a table and a bit of code to parse the values you store there.

I agree that you don't need a service for this, but these things tend to quickly grow much larger than "just a field in a table and a bit of code"

That's why the services exist and have value.

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

#107

Post by BossingAround » Fri, Jan 28, 2022, 7:46 PM UTC

How do folks implement feature flags? Do most people use feature flags as "remove/add code from/to my application at compile time"? Or do people also use some kind of a runtime check system that enables them to toggle functionality while the application is running with some partial reloads or fast restarts?

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

#108

Post by yojo » Fri, Jan 28, 2022, 8:09 PM UTC

nicoburns wrote: post #104

yojo wrote: post #84

Earlier quoted context omitted.

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 t…

> 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. Ah, we're small enough that we don't have a marketing team and we don't have capacity to do A/B testing either!

Ah yeah. The right answer to this question looks very different depending on how old/mature your codebase is and how big your eng team is.

My example is from a ~1200 person eng org with a ten year old codebase.

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

#109

Post by janglezz » Fri, Jan 28, 2022, 8:10 PM UTC

All the time. We use Optimizely which allows us to roll features out to subsets of users and run experiments.

It also allows us to keep PRs smaller and roll stuff out to prod confidently.

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

#110

Post by timothyfcook » Fri, Jan 28, 2022, 8:18 PM UTC

Recently worked at a mid-sized learning technology company. Feature flags were transformative for our product delivery to fully decouple deploys from releases, reduce risk, and offer tons of control over feature rollouts. Really can't imagine releasing without them.

In my new role, I'm curious what teams do with feature flags post-release. Do you have a good process for cleaning them up? Do they have long term usefulness as a failsafe or for customer/user configuration? Is it really an issue if they just stay in the code forever? Does this cause issues for you?