Feature Flags: Theory vs. Reality

- local/static access: it should not have to call out to a 3rd party server to get basic runtime config

- unused-flag detection: flags should have three reported states: never used, recently used, not recently used. These will be different from the user-controlled states of active, inactive, etc.

- sticky a/b testing: should follow the logged in user until the flag is removed

- integration with logger: I should be able to use it with my logger out of the box to report only relevant feature flags. Alternatively can provide a packed value of all relevant flags, would probably have to do flag state versioning.

- integration with linter: should warn me if flag has not recently been used or I used a flag in the code that is not in our database (alternatively, will upsert the flag automatically if it doesn’t exist)

- hashed flag names on frontend build: prevent the leakage of information, not a perfect solution, but I would want to avoid writing “top-secret-feature” where we can.

I fully acknowledge that a lot of solutions come close, but I haven’t looked at the current state of things in the last few years so it may have improved.

This is what drove me to build an open source solution: https://featurevisor.com/

One of the reasons I went for an open source solution ( https://featurevisor.com ) that's Git based, and every change is done via Pull Requests.

Building blocks:

- Attributes for conditions: https://featurevisor.com/docs/attributes/

- Segments for targeting users: https://featurevisor.com/docs/segments/

- Features with variations and rules: https://featurevisor.com/docs/features/

Process:

- Merge PRs

- Trigger CI/CD pipeline: https://featurevisor.com/docs/deployment/

- Consume with SDK: https://featurevisor.com/docs/sdks/

Use cases:

- User entitlements: https://featurevisor.com/docs/use-cases/entitlements/

- Testing in production: https://featurevisor.com/docs/use-cases/testing-in-productio...

- A/B testing & experimentation: https://featurevisor.com/docs/use-cases/experiments/

- Remote configuration: https://featurevisor.com/docs/use-cases/remote-configuration...

You can also generate types as a package for compile-time safety:

- Code generation: https://featurevisor.com/docs/code-generation/

The post and the comments here give me more ideas on how to improve it with more features now.

That said, I'm surprised this article doesn't mention the two words that always come to my mind when I see toggles: combinatorial explosion. Several times I've worked on projects that went way too toggle-happy and decided that new functionality should be split into indefinite life "features". Just in case the company someday wants to sell a model without that feature. Of course, when an old toggle finally gets turned off a year later, you realize that it crashes the system because several other features kind of half depend on them.

What happens when your homegrown feature flag microservice (because why pay for a hard cost when you can have the soft cost of making your own) goes down, even temporarily.

Sane defaults at code review time, before launch aren't always the sane defaults after a feature has fully launched, or nearly fully launched.

I've seen more than a few egregious outages due to a feature flagging tool being down and taking the user experience back a year or two.