4 ms·

When reading your comment, it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at

When reading your comment, it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already. For me feature flags go along with trunk based development to enable features in QA settings, but not on PROD yet, for PO/PM testing. Trunk based development allows for fast/easy devops, without complicated branching strategies. Application configuration is, for me, part of the application and has the business context for customizing the application accordingly. Not sure if there are specific frameworks/tools out there. But one should clearly distinguish these two.

epolanski 4mo ago
> it just reminds me on how feature flags can be misused as application configuration/customization They literally are configuration.
- tedk-42 4mo ago
  Oh yeah lets make a web request per service invocation to figure out what to serve for the invocation! Guys this is exactly the kind of banal crap that makes a simple app into a monsterous beast that won't work unless it's connected to the internet.
  - epolanski 4mo ago
    There's no web request per service invocation. Feature flags are set once at startup (or specific events like hard refresh, or new login) and then simply included in the request headers. It's not rocket science, but I'm sure people are free to overcomplicate it.
    - tedk-42 4mo ago
      That's not a feature flagging service then (config as a service! not a thing really...) I've done both client and server side implementations of the launch darkly sdk and that's how it's done to know client context. If you're initialising the entire SDK only to load 1 set of configuration items, I'd argue you can host the config as a json file on a CDN and be done with it - feature flagging is overkill.
      - epolanski 4mo ago
        Then I'm lost at what the difference would be and why do you need a dedicated service. Pardon my ignorance.
        tedk-42 4mo ago
        All good - it is something that has been over-complicated for marketing/product reasons. If you know what A/B testing is, feature flagging can really allow you to nail down how you should deliver an experience to an end user. We track end-to-end engagements on our websites based on how the content is displayed on a page with more performant layouts/content winning the test to drive users through the funnel. I don't love it though because it's a lot of waste that gets left over and not cleaned up leaving billing to grow exponentially as flags are continually called for no reason.
baq 4mo ago
> it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already. feature flags are perfect for configuration and customization, why using them for this purpose is 'misuse' is beyond me and I've heard this claim from multiple people. they're literally configuration. feature with a flag to turn it on, off or give the flag a value. where's the misuse? is it a problem I'm not running experiments when switching over redis to valkey or whatever?
- ZephyrBlu 4mo ago
  Feature flags need to be treated as short-lived and experimental otherwise they end up getting abused for everything and make it very difficult to reason about your application. If it's config/customization, it should be in code. If it's experimental it can be a flag until it solidifies, and then it needs to get moved to code. When I was at Shopify a couple of years ago they mandated that feature flags had to be short-lived (Like 2-4w lifetime tops, some had exceptions) because they would end up getting left in code and never cleaned up, or for extended periods of time like months. Hard to tell if it's genuinely a "feature flag" or actually just a normal part of the system at that point. Feature flags being flipped in prod was also a major source of incidents, in part because people didn't treat them as experimental and with the associated risk profile of something experimental. The only exception where having long-lived flags was useful and required was for operational killswitches (E.g. disable Apple Pay because it's having issues), but that is explicitly not application config.
  - baq 4mo ago
    I disagree with just about everything you said being a problem except the process of cleaning up is absolutely required. Notably feature flags triggering incidents is expected and desired vs the alternative of shipping the code and having to roll a release back because there is no other way to remove the feature from prod.
    - ZephyrBlu 4mo ago
      In a company the size of Shopify people flipping their feature flags would very often impact *other teams*, and like I said feature flags got abused with even seemingly innocuous changes being put behind them or being left long periods of time before being fully used. When someone else flips a flag that impacts your team and they have no idea they even caused a problem, it becomes very difficult to resolve the issue. Usually you can check for recent deploys, instead you have to go and guess at which feature flag which was recently flipped could possibly be affecting your code. I experienced this several times. Also, it was actually more desirable for most of these things to go straight to production. Test it properly before shipping, then when you ship it soaks on a 5% traffic canary at which point you can monitor and cancel the deploy if you see errors. That is generally safer than a feature flag rollout unless you are doing something very high impact/risk, in large part because it gives any other team affected by your rollout the ability to respond and be able to easily find the source of errors. In my org it was a fairly common failure mode to ship something and accidentally cause an issue for another team. Usually it was other teams/orgs shipping things that impacted us.
chambers 4mo ago
Yes, feature flags are conflated with remote configs (or its more useful variety: "dynamic configs"). The difference is subtle, hence why people are talking past each other. Feature flags are gates for whether a piece of code runs; basically, an if-condition. Remote configs are a mechanism for changing runtime values without redeploying[1]. For example: # Feature flag — variant gate for rollout flag = sdk.check_gate(user, "checkout_flow") if flag == 'open': render_new_checkout() elif flag == 'warning': render_warning_checkout() else: render_old_checkout() # Raw remote config pulled — structured values for tuning behavior config = sdk.get_config(user, "checkout_settings") # if the config changes based on user or context, this "remote" config is considered "dynamic" timeout_ms = config.get("timeout_ms", 5000) max_items = config.get("max_items", 50) allowed_tlds = config.get("allowed_tlds", [".com", ".org"]) In practice, feature flags are implemented on top of dynamic configs[2] to manage the temporary lifecycle of a feature — aka, ship a new block of code, ramp its execution up to 100%, then delete the flag. Whereas dynamic configs are a deeper primitive meant for semi-permanent/safer operations like tuning rate limits or changing text copy on a marketing website. As I've seen it: the forcing function that separates the concepts are experimentation platforms: when human-control of feature flags is shared (via dynamic configs) with automated & randomized assignments. That's how Statsig built their system and, in part, why they could sell for a billion. Whereas companies that ignored the difference, like LaunchDarkly, struggled outside of feature flags. [1] https://engineering.atspotify.com/2020/10/spotifys-new-experimentation-platform-part-1 https://engineering.atspotify.com/2020/10/spotifys-new-exper... [2] https://docs.statsig.com/dynamic-config/overview https://docs.statsig.com/dynamic-config/overview https://blog.x.com/engineering/en_us/topics/infrastructure/2018/dynamic-configuration-at-twitter https://blog.x.com/engineering/en_us/topics/infrastructure/2...
- tailscaler2026 4mo ago
  I think feature flags, remote configs, and experiments are all the same thing. Semantically they differ in how you're applying the config and interpreting the outcomes.

epolanski 4mo ago

> it just reminds me on how feature flags can be misused as application configuration/customization They literally are configuration.

tedk-42 4mo ago
Oh yeah lets make a web request per service invocation to figure out what to serve for the invocation! Guys this is exactly the kind of banal crap that makes a simple app into a monsterous beast that won't work unless it's connected to the internet.
- epolanski 4mo ago
  There's no web request per service invocation. Feature flags are set once at startup (or specific events like hard refresh, or new login) and then simply included in the request headers. It's not rocket science, but I'm sure people are free to overcomplicate it.
  - tedk-42 4mo ago
    That's not a feature flagging service then (config as a service! not a thing really...) I've done both client and server side implementations of the launch darkly sdk and that's how it's done to know client context. If you're initialising the entire SDK only to load 1 set of configuration items, I'd argue you can host the config as a json file on a CDN and be done with it - feature flagging is overkill.
    - epolanski 4mo ago
      Then I'm lost at what the difference would be and why do you need a dedicated service. Pardon my ignorance.
      - tedk-42 4mo ago
        All good - it is something that has been over-complicated for marketing/product reasons. If you know what A/B testing is, feature flagging can really allow you to nail down how you should deliver an experience to an end user. We track end-to-end engagements on our websites based on how the content is displayed on a page with more performant layouts/content winning the test to drive users through the funnel. I don't love it though because it's a lot of waste that gets left over and not cleaned up leaving billing to grow exponentially as flags are continually called for no reason.

baq 4mo ago

> it just reminds me on how feature flags can be misused as application configuration/customization. An antipattern i could observe at various organzations already. feature flags are perfect for configuration and customization, why using them for this purpose is 'misuse' is beyond me and I've heard this claim from multiple people. they're literally configuration. feature with a flag to turn it on, off or give the flag a value. where's the misuse? is it a problem I'm not running experiments when switching over redis to valkey or whatever?

ZephyrBlu 4mo ago
Feature flags need to be treated as short-lived and experimental otherwise they end up getting abused for everything and make it very difficult to reason about your application. If it's config/customization, it should be in code. If it's experimental it can be a flag until it solidifies, and then it needs to get moved to code. When I was at Shopify a couple of years ago they mandated that feature flags had to be short-lived (Like 2-4w lifetime tops, some had exceptions) because they would end up getting left in code and never cleaned up, or for extended periods of time like months. Hard to tell if it's genuinely a "feature flag" or actually just a normal part of the system at that point. Feature flags being flipped in prod was also a major source of incidents, in part because people didn't treat them as experimental and with the associated risk profile of something experimental. The only exception where having long-lived flags was useful and required was for operational killswitches (E.g. disable Apple Pay because it's having issues), but that is explicitly not application config.
- baq 4mo ago
  I disagree with just about everything you said being a problem except the process of cleaning up is absolutely required. Notably feature flags triggering incidents is expected and desired vs the alternative of shipping the code and having to roll a release back because there is no other way to remove the feature from prod.
  - ZephyrBlu 4mo ago
    In a company the size of Shopify people flipping their feature flags would very often impact *other teams*, and like I said feature flags got abused with even seemingly innocuous changes being put behind them or being left long periods of time before being fully used. When someone else flips a flag that impacts your team and they have no idea they even caused a problem, it becomes very difficult to resolve the issue. Usually you can check for recent deploys, instead you have to go and guess at which feature flag which was recently flipped could possibly be affecting your code. I experienced this several times. Also, it was actually more desirable for most of these things to go straight to production. Test it properly before shipping, then when you ship it soaks on a 5% traffic canary at which point you can monitor and cancel the deploy if you see errors. That is generally safer than a feature flag rollout unless you are doing something very high impact/risk, in large part because it gives any other team affected by your rollout the ability to respond and be able to easily find the source of errors. In my org it was a fairly common failure mode to ship something and accidentally cause an issue for another team. Usually it was other teams/orgs shipping things that impacted us.

chambers 4mo ago

Yes, feature flags are conflated with remote configs (or its more useful variety: "dynamic configs"). The difference is subtle, hence why people are talking past each other. Feature flags are gates for whether a piece of code runs; basically, an if-condition. Remote configs are a mechanism for changing runtime values without redeploying[1]. For example: # Feature flag — variant gate for rollout flag = sdk.check_gate(user, "checkout_flow") if flag == 'open': render_new_checkout() elif flag == 'warning': render_warning_checkout() else: render_old_checkout() # Raw remote config pulled — structured values for tuning behavior config = sdk.get_config(user, "checkout_settings") # if the config changes based on user or context, this "remote" config is considered "dynamic" timeout_ms = config.get("timeout_ms", 5000) max_items = config.get("max_items", 50) allowed_tlds = config.get("allowed_tlds", [".com", ".org"]) In practice, feature flags are implemented on top of dynamic configs[2] to manage the temporary lifecycle of a feature — aka, ship a new block of code, ramp its execution up to 100%, then delete the flag. Whereas dynamic configs are a deeper primitive meant for semi-permanent/safer operations like tuning rate limits or changing text copy on a marketing website. As I've seen it: the forcing function that separates the concepts are experimentation platforms: when human-control of feature flags is shared (via dynamic configs) with automated & randomized assignments. That's how Statsig built their system and, in part, why they could sell for a billion. Whereas companies that ignored the difference, like LaunchDarkly, struggled outside of feature flags. [1] https://engineering.atspotify.com/2020/10/spotifys-new-experimentation-platform-part-1 https://engineering.atspotify.com/2020/10/spotifys-new-exper... [2] https://docs.statsig.com/dynamic-config/overview https://docs.statsig.com/dynamic-config/overview https://blog.x.com/engineering/en_us/topics/infrastructure/2018/dynamic-configuration-at-twitter https://blog.x.com/engineering/en_us/topics/infrastructure/2...

tailscaler2026 4mo ago
I think feature flags, remote configs, and experiments are all the same thing. Semantically they differ in how you're applying the config and interpreting the outcomes.