This domain needs some better ontology and taxonomy, there's so many overlapping and conflated terms whenever I hear about it. To name a few:

- Feature Flags used as Configs;

- Configs used as Feature Flags;

- Live Ops, Control Groups, Experiments, Analytics, and more bundled as "extras" to Feature Flags as if they were the right parent term;

I think classical systems/engineering see feature flags as boolean state in some data store, but these PaaS are pushing it as a new thing and struggling with marketing.

I wish they took the gaming companies lesson and started using the term "Live Ops"

▲

rafabulsing 2 days ago | parent | next [-]

This article does exactly that, you might find it an interesting read: https://martinfowler.com/articles/feature-toggles.html

	▲	hmokiguess 2 days ago \| parent [-]
		Oh wow I didn't know about this one, thanks for sharing! Great read

▲

kalcode 2 days ago | parent | prev [-]

To me there two type of feature flag. For tech and not for tech.

If you have good CI/CD practices, an ENV for the environment has what feature is simplest. No new dependencies, change code commit deploy.

Non-tech folks need something else that allows them to switch it on and then off. For a variety of reasons.

▲

figmert 2 days ago | parent | next [-]

Ex-LaunchDarkly engineer here.

Feature management goes well beyond an env var. Sure an env var change is fine on it's own, but a change of the feature flag (essentially a release) requires a deployment.

Feature management separates these two. You can deploy without releasing. Because the code is there, but dormant behind an if that can change at runtime, you can actually target users, segments, or even do progressive rollout, and so much more. What this also means is you can test your changes in production without causing prod to go down. Best of all, a release doesn't mean a bad deployment.

It's not just about non-tech folks. It separates deploy and release in the SDLC, and that opens up a whole new world.

	▲	kalcode a day ago \| parent [-]
		I used LaunchDarkly I agree but it depends on your practices. Proper CI/CD means potentials hundreds of deployments a week. A deployment is nothing in some environments. And the change gets tracked into the environment that has it switched, into our logs and other observaility platforms. So we get the same info. LaunchDarkly was amazing when coordinating with stakeholders and product owners. Especially for testing features, A/B, etc. I'm definitely not trying to downplay it, but starting with just ENVs for each place is simplest and then they can expand into tools they need like LaunchDarkly or PostHog. But starting there for small engi teams isn't as valuable. That's all, not against it for a product that builds to it, but just too much churn for smaller teams to use. I still advise ENV first. And yah the realtime flags of LaunchDarkly were amazing , I needed that a few times.

▲

ctkhn 2 days ago | parent | prev | next [-]

We had a weird constellation of these things at a previous job of mine. In addition to our env variables, we had a config table for more business-side stuff (ie percent of margin to include in bids and quotes for work on the platform) that our business team would upload new values to on our admin GUI with a CSV file, and eventually we jammed into that same table a config check that would enable features just for certain users by email. I was very happy when we eventually moved to Launchdarkly and tossed out the hacky stuff.

▲

VulgarExigency 2 days ago | parent | prev [-]

This seems a bit reductive. What if you want to do a progressive rollout of the feature? What if it has a problem, and you want to disable it without needing to redeploy across multiple regions? What if you want to A/B test it?