Omission of a feature flag should not be the same as false

[elwayman02]

Omitting a feature flag should not be interpreted the same as setting a feature flag to false. This limits the scope of feature flags significantly, as it makes it arduous to permanently turn off a feature flag. This is what I've seen as the optimal feature flag workflow:

1. Develop a new feature under a feature flag (flag is true in dev env, false in production)
2. When feature is ready for beta testing in production, set to true in production
3. When feature is stable in production, remove flag entirely from feature flag list
4. After removing flag entirely, refactor code as time/bandwidth allows to remove checks for that feature flag

This means that applications don't have to track a list of feature flags that are always set to true in every environment. You shouldn't need to maintain feature flags indefinitely, their main value is in being set to false to disable a feature in production while allowing its code to be shipped as part of the app so as to avoid long-lived unmerged feature branches.

@jasonmit @thoov might have thoughts on this as well, as they're familiar with the above process I mentioned.

[kategengler]

I disagree; having omissions be effectively false is safe default. I wouldn't want to turn a feature on in production by accidental omission of the flag.

This doesn't prevent usage of feature flags for continuous delivery, as you say, their main value, you just need to maintain your list of feature flags. Frequently cleaning up the branching based on them is a good practice, as is having feature than a handful of active ones.

[elwayman02]

Constantly maintaining the list of enabled feature flags is, in my opinion, a huge downside of this addon. It creates a lot of organizational overhead, whereas it's very hard to accidentally omit a flag in production if you simply always set features to false when adding them to the config. The only way to omit them at that point is to purposefully remove them from the config, which is a very deliberate action.

[kategengler]

This addon can set feature flags in other ways than in config.js. I primarily set them from an API provided by a backend, and I set them by environmental configuration (and sometimes by user) rather than prod/staging/dev. It allows me to turn on a feature in staging just for QA.

It is not hard to omit a flag in production in such scenarios; I've seen it happen. I've also seen it happen when they are set in config, its very easy to add a feature flag in code and not set it in config at all. Defaulting to false is also aligned with the server side implementations of feature flags that I've encountered.