No -- to me they are a code smell.
Ask HN: Does your team use feature flags?
51–60 of 143 posts
Re: Ask HN: Does your team use feature flags?
#52Not frontend but I use them extensively now in backend + REST endpoints. I still think they are necessary to prevent having to hotfix builds when something breaks with a new feature, however I don't think they are purely good. Too many feature flags add a lot of complexity to the testing surface of a project and if the test suite isn't well adapted to test all the configurations then people will end up unit testing their feature flag (if they do at all) and not doing any kind of integration testing of the specific combination of flags that production may find itself in. You need to have a well thought out test suite.
Re: Ask HN: Does your team use feature flags?
#53Yes. I've worked at a few places that have used them similarly. Some do call them "feature flags", others call them "permissions". As others are noting in the comments here, they are great to perform partial rollouts of new features, or to selectively grant users (both for a client or just for our own in house purposes) the ability to see how a feature will run in a real world scenario. One company created a category…
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 organization we were consistently failing to clean up flags.
Re: Ask HN: Does your team use feature flags?
#54No, 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!
Feature flags can be used as a gate for in progress code. This is common in companies that enforce a linear commit history and encourage many frequent, small commits. It helps avoid merge conflicts that could happen with long living feature branches.
Re: Ask HN: Does your team use feature flags?
#55Yes. I've worked at a few places that have used them similarly. Some do call them "feature flags", others call them "permissions". As others are noting in the comments here, they are great to perform partial rollouts of new features, or to selectively grant users (both for a client or just for our own in house purposes) the ability to see how a feature will run in a real world scenario. One company created a category…
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
Re: Ask HN: Does your team use feature flags?
#56Earlier 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?
Sure, though if your back-end has multiple services this becomes harder. If your back-end uses more than one server, then you can run into issues.
Feature flags also let you do partial rollouts, where you release to 0.1% of users and see if stuff breaks. Or A/B test to see if your feature improves whatever its meant to improve. It also lets you roll out the feature selectively to certain users if it's a breaking changes and each user needs time to migrate.
Re: Ask HN: Does your team use feature flags?
#57I haven't seen them used on any of the projects I've worked on. HN is really the only place I regularly hear about feature flags, actually.
HN seems like 90% web developers, and I don't really see the point outside of the web. I mean, we have other ways of gradually rolling out and configuring new software builds.
Re: Ask HN: Does your team use feature flags?
#58A 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 might have work-arounds like an artificial load tester, but nothing beats true production traffic & patterns.
Re: Ask HN: Does your team use feature flags?
#59No, never used them in the past, but I'd like to give them a try for my next project.
Anyone got any good guides for building a feature flag system from scratch? ( I'm not interested in just importing a dependency, I want to properly understand how this works)
Re: Ask HN: Does your team use feature flags?
#60Earlier 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
This really depends on the use case.
For example, consider a platform where users can sign up to post or listen to music. There might be three types of user: "listener", "artist", and "label". There may be permissions and configuration settings that would cater to each one of these types within the same interface, and maybe in some exceptional cases, they could be intermixed (eg: while an artist and label can post music, maybe an artist can also track stats about what they like to listen to, something that only a listener account can do normally).
The platform might want to configure each of these to streamline usage and to remove features that aren't relevant to that account type, but some accounts may be specialized for whatever reason.