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

Principles for building and scaling feature flag systems

docs.getunleash.io

Post reply on HN
Print view View original

51–60 of 115 posts

Re: Principles for building and scaling feature flag systems

#51

Post by blawson »

zellyn wrote: post #8
zellyn wrote: post #6

Background: I work at Block/Square, on the team that owns (but didn't build) our internal Feature Flag system, and also have a lot of experience with using LaunchDarkly. I like the idea of caching locally, although k8s makes that a bit more difficult since containers are typically ephemeral. People will use feature flags for things that they shouldn't, so eventually "falling back go default values" will cause product…

One more update. I spent a little time the other day trying to find all the feature flag products I could. I'm sure I missed a ton. Let me know in the comments! LaunchDarkly Split Apptimize CloudBees ConfigCat DevCycle FeatBit FeatureHub Flagsmith Flipper Flipt GrowthBook Harness Molasses OpenFeature Posthog Rollout Unleash Here's my first draft of the questions you'd want to ask about any given solution: Questionnai…

Togglz is another option: https://www.togglz.org/

Re: Principles for building and scaling feature flag systems

#52

Post by hamandcheese »

adasdasdas wrote: post #45

More principles - Require in code defaults for fault tolerance - Start annoying the flag author to delete if the flag is over a month old - Partial rollout should be by hash on user id - Contextual flag features should always be supplied by client (e.g. only show in LA, the location should be provided by client)

> Partial rollout should be by hash on user id

With a per-flag salt as well, otherwise the same user will always have bad luck and be subject to experiments first.

Re: Principles for building and scaling feature flag systems

#53

Post by dgorton »

zellyn wrote: post #21
daigoba66 wrote: post #11

Earlier quoted context omitted.

> One best practice that I'd love to see spread (in our codebases too) is always naming the full feature flag directly in code, as a string (not a constant). Can you elaborate on this? As a programmer, I would think that using something like a constant would help us find references and ensure all usage of the flag is removed when the constant is removed.

One of the most common things you want to do for a feature flag or metric name is ask, "Where is this used in code?". (LaunchDarkly even has a product feature that does this, called "Code References".) I suppose one layer of indirection (into a constant) doesn't hurt too much, although it certainly makes things a little trickier. The bigger problem is when the code constructs metric and flag names programmatically: p…

Agreed. Flags are a type of technical debt. Keeping them as full strings in the code encourages and facilitates cleanup.

This sort of programmatic naming is a dangerous step down a slippery slope.

Re: Principles for building and scaling feature flag systems

#54

Post by konradlekko »

zellyn wrote: post #8
zellyn wrote: post #6

Background: I work at Block/Square, on the team that owns (but didn't build) our internal Feature Flag system, and also have a lot of experience with using LaunchDarkly. I like the idea of caching locally, although k8s makes that a bit more difficult since containers are typically ephemeral. People will use feature flags for things that they shouldn't, so eventually "falling back go default values" will cause product…

One more update. I spent a little time the other day trying to find all the feature flag products I could. I'm sure I missed a ton. Let me know in the comments! LaunchDarkly Split Apptimize CloudBees ConfigCat DevCycle FeatBit FeatureHub Flagsmith Flipper Flipt GrowthBook Harness Molasses OpenFeature Posthog Rollout Unleash Here's my first draft of the questions you'd want to ask about any given solution: Questionnai…

A few more: https://featurevisor.com/ https://configcat.com/

I will toss our hat in the ring but we are early in this space! https://lekko.com

Re: Principles for building and scaling feature flag systems

#55

Post by dabeeeenster »

For those that dont know about the project, check out Open Feature https://openfeature.dev/ which is sort of like Open Telemetry but for feature flags. Helps avoid vendor lock in. We're a young project and looking for help and to build the community!

Re: Principles for building and scaling feature flag systems

#57

Post by tantalor »

mabbo wrote: post #12

> Make feature flags short-lived. Do not confuse flags with application configuration. This is my current battle. I introduced feature flags to the team as a means to separate deployment from launch of new features. For the sake of getting it working and used, I made the mis-step of backing the flags with config files with the intent to get Launch Darkly or Unleash working ASAP instead to replace them. Then another d…

Sounds like "other dev" found some business case they could unblock with existing system, and you thought the business was better off not solving that, or finding a more expensive solution.

Curious how you plan to justify cost to "fix it" to management. If it ain't broke...

Re: Principles for building and scaling feature flag systems

#58

Post by tantalor »

adasdasdas wrote: post #45

More principles - Require in code defaults for fault tolerance - Start annoying the flag author to delete if the flag is over a month old - Partial rollout should be by hash on user id - Contextual flag features should always be supplied by client (e.g. only show in LA, the location should be provided by client)

> Start annoying the flag author to delete if the flag is over a month old

No problem, filter that email directly to spam folder.

Re: Principles for building and scaling feature flag systems

#59

Post by llbeansandrice »

gastonfournier wrote: post #27
mabbo wrote: post #12

> Make feature flags short-lived. Do not confuse flags with application configuration. This is my current battle. I introduced feature flags to the team as a means to separate deployment from launch of new features. For the sake of getting it working and used, I made the mis-step of backing the flags with config files with the intent to get Launch Darkly or Unleash working ASAP instead to replace them. Then another d…

I faced something similar, and I think it's unavoidable. Give people a screwdriver and they'll find a way of using it as a hammer. The best you can do is expect the feature flagging solution to give some kind of warning for tech debt. Then equip them with alternative tools for configuration management. Rather than forbidding, give them options, but if it's not your scope, I'd let them be (I know as engineers this is…

> Give people a screwdriver and they'll find a way of using it as a hammer.

I feel like feature flags aren't that far off though. They're fantastic for many uses of runtime configuration as mentioned in another comment.

There's multiple people in this thread complaining about "abuse" of feature flags but no one has been able to voice why it's abuse instead of just use beyond esoteric dogma.

Re: Principles for building and scaling feature flag systems

#60

Post by ignoramous »

rubicon33 wrote: post #35
baq wrote: post #31

Earlier quoted context omitted.

Or... see them for what they are: runtime configuration. The name implies a use case scenario, but in reality it's just a configuration knob. With a good UI, it's a pretty damn convenient way to do runtime configuration. So of course they'll be used for long-term configuration purposes, especially under pressure and for gradual rollouts of whole systems, not just A/B testing features.

This hits the nail on the head. The term "feature flag" has come to inherently have a time component because features are supposed to eventually be fulled GA'd. What I've seen in practice is feature flags are never removed so a better way to think about them is as a runtime configuration.

> What I've seen in practice is feature flags are never removed so a better way to think about them is as a runtime configuration.

SaaS won't sell itself unless it redefines the problem and presents itself as a solution...

Post reply on HN