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

131–140 of 143 posts

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

#131

Post by rudasn »

bluefirebrand wrote: post #130

We rarely use them where I work although we've recently had some devs who are trying to get us to adopt it. Personally I think they should be used sparingly for things where you have to be able to configure the same software on different environments differently, for purposes of A/B testing or other such things. Using them a lot increases your code complexity and is basically just tech debt imo. The gain is that you…

For me the biggest take away from this thread is the distinction between release, deploy, and launch. So no matter how good or bad your CI/CD process is, you can still control what gets launched, when, and to whom.

I did not know about the term as such, but after reading about it I realised that it's something that our very small team (I can see how being more formal about it can help small teams, especially when they want to have high velocity but do not the capacity to test the hell out of everything, or simply have to support alternate features at the same time.

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

#132

Post by cammil »

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…

Where did you store the flag? In code? App config? Or operational data store?

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

#133

Post by rognjen »

Perspective from a small startup: we used feature flags mainly for two types of features: 1. complex and 2. affects money.

Complex: when you roll out a complex feature, it's best to not make it available to all. Instead, focus on a small trusted subset of savvy users who will be easier to train. At the same time, you can use their experience with it to simplify it and make it easier for the rest of the userbase.

Money: we ran a marketplace so dealt with clients' money. We quickly realized that changes to the way payments are processed needed extensive feedback. Even if we assumed something was alright, chances are there would be objections. Rolling out changes in stages would allow our team to handle complaints and feedback without being overwhelmed.

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

#134

Post by npteljes »

BossingAround wrote: post #107

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?

The most elaborate I've seen IRL is when feature flag management was handled by a service, so they were handled at runtime. The service authenticated the user and then returned a bunch of flags for them. The service also had a web interface for admins to modify the flags; they could be specified on different levels, like system, user, group. The flag service was always called by the backend, so if the frontend needed the flags, the backend forwarded it to them. For a select few flags, the users themselves could toggle them, on a simple interface.

The simplest I've done on a small project was just if blocks that checked the username. We had just a few, long term users, and this was used to handle their unique requirements.

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

#135

Post by rubyist5eva »

Yes. It’s the only way we’ve found to be able to deliver large features in a timely manner without a giant push at the end before launch because all functionality is tested internally and delivered by deployed in a dark launch. Separating deployment from launch was one of the biggest improvements to our ability to deliver value to the business.

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

#136

Post by neebz »

alunchbox wrote: post #96
neebz wrote: post #93

Yes. Feature flags changed the mindset of my whole team. I absolutely love the fact that it pushes the whole team towards release-small-release-often mentality. It's a technical solution with many benefits but I love the cultural impact the most.

We're currently in the transition, any chance you have some insights to help ease the mentality shift as the team transitions to this vs bi-weekly/monthly deployments.

Some feedback from our transition:

- automated tests are the pre-req of feature flags. kindly make sure that you have good test coverage. otherwise the team loses confidence in code & feature flags which defeats the whole purpose.

- as part of code review guidelines we added one major feedback item: can this PR be merged right now? why not? what can be done to merge it right away? as part of a cultural shift the code reviewers played a critical role. they kept engineers on the their toes at all times.

- feature flags should be part of user stories. in many cases you can't expect engineers to add a feature flag at the end of implementation. the product team should know this at the time of writing user stories.

- as mentioned in many other comments try to clean up code after feature flags become stale. otherwise the code (and respective automated test cases) becomes a huge mess.

- in our case we decided the granularity of feature flags (per-user, per-customer, per-region, per-server etc). we started with per-customer and went from there. worked out fine for us.

- feature flags have major two benefits: "release often, release small" & "decouple releases with big launches". please make sure to instill this in your team every day. mindset changes takes repetition and emphasis. if at anytime you feel that you are not achieving any of these please take a step back and figure out why.

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

#137

Post by bluefirebrand »

rudasn wrote: post #131
bluefirebrand wrote: post #130

We rarely use them where I work although we've recently had some devs who are trying to get us to adopt it. Personally I think they should be used sparingly for things where you have to be able to configure the same software on different environments differently, for purposes of A/B testing or other such things. Using them a lot increases your code complexity and is basically just tech debt imo. The gain is that you…

For me the biggest take away from this thread is the distinction between release, deploy, and launch . So no matter how good or bad your CI/CD process is, you can still control what gets launched, when, and to whom. I did not know about the term as such, but after reading about it I realised that it's something that our very small team ( I can see how being more formal about it can help small teams, especially when t…

We manage this with branches in git.

I think if you don't want certain features on production it's better to just not have them in the production branch. Putting them behind a feature flag always allows for a misconfiguration where suddenly a half built feature is visible and broken in production. It might be a small risk, but why take it?

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

#138

Post by citrusx »

We do. But, depending on your project, you may need to do extra work to corral the complexity that can grow up around them. We wrote a library for using them in our web apps that allows us to use them, and remove them, easily.

Some possible failures that can happen with feature flags: 1) "Accidentally perpetual" - Since feature flags are a part of the code, it's easy to create multiple dependencies on the flag value, which makes it difficult to remove from the code without mysterious null exceptions happening where you didn't expect them. 2) Cross-scope - Using multiple feature flags carelessly can result in situations where one flag value change doesn't do what's expected unless another flag's value is present or set to a certain value. Flags should always be independent from one another, even if they're controlling the same code. Instead of two flags whose values affect each other, you would instead create more flags (4, in the case here if using Boolean flags) to reflect each combined state. 3) Fallback - What happens if the systems or SaaS that supplies your feature flags becomes unavailable? Always consider this.

Feature flags are a great tool, and enabling your team to be able to "test in production" with them can be amazing. However, do watch out for the footguns.

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

#139

Post by rudasn »

bluefirebrand wrote: post #137
rudasn wrote: post #131

Earlier quoted context omitted.

For me the biggest take away from this thread is the distinction between release, deploy, and launch . So no matter how good or bad your CI/CD process is, you can still control what gets launched, when, and to whom. I did not know about the term as such, but after reading about it I realised that it's something that our very small team ( I can see how being more formal about it can help small teams, especially when t…

We manage this with branches in git. I think if you don't want certain features on production it's better to just not have them in the production branch. Putting them behind a feature flag always allows for a misconfiguration where suddenly a half built feature is visible and broken in production. It might be a small risk, but why take it?

> think if you don't want certain features on production it's better to just not have them in the production branch

Totally agree. In our case however, we used a feature flag when launching a new feature for the first time (a new way to render pdfs) that depended heavily on Per-customer configuration (eg their letterhead/logo) and on the data being rendered, that also had very strict requirements (number of pages, etc). The only to "test" this was in production and it's something that must be reversible in an instant by us or the particular client (ie no redeployment or anything like that).

I guess it depends on the context as well, since we do b2b and on-prem, so there's no such thing as "move fast and break things". Our clients actually require slow moving, incremental, updates that never break things, and it's a bit of a pain for us to do deployments / updates (it takes time, even if kind of automated/scripted).

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

#140

Post by bluefirebrand »

rudasn wrote: post #139
bluefirebrand wrote: post #137

Earlier quoted context omitted.

We manage this with branches in git. I think if you don't want certain features on production it's better to just not have them in the production branch. Putting them behind a feature flag always allows for a misconfiguration where suddenly a half built feature is visible and broken in production. It might be a small risk, but why take it?

> think if you don't want certain features on production it's better to just not have them in the production branch Totally agree. In our case however, we used a feature flag when launching a new feature for the first time (a new way to render pdfs) that depended heavily on Per-customer configuration (eg their letterhead/logo) and on the data being rendered, that also had very strict requirements (number of pages, et…

See, and that's an entirely reasonable scenario to require feature flags for. In my mind it's always been a thing to add only when you actually need to toggle a feature without a deploy. Certainly not something to sprinkle in your code liberally.

A lot of people in this thread seem to disagree and I find it fairly baffling.

Post reply on HN