alt Hacker NewsWhen 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.
Replies
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"])
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-exper...
[2] https://docs.statsig.com/dynamic-config/overview https://blog.x.com/engineering/en_us/topics/infrastructure/2...
> it just reminds me on how feature flags can be misused as application configuration/customization
They literally are configuration.
> 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?