1. 4

Refers to: https://remimercier.com/minimal-feature-flags-manager/

  1. 6

    I think the author is conflating preferences with features. To me a “feature flag” implies some kind of significant behavioral change or addition. In many cases such changes have significant impact on the state on runtime data structures such that changing the behaviour after the initialization of the core program state isn’t a sound option.

    That said a centralized settings/preferences store is just as reasonable.

    1. 2

      I’ve mostly seen feature flags to vary at run time if a feature is availble to a given entity. such as enabling a gradual rollout of a new chunk of behaviour. So while there will be cases where you do have to handle forward and backwards compatible versioning, I’ve never seen it used for something that’s as fundamental as you imply. Then again, I’ve mostly seen it used purely on the stateless tier of business systems.

      In many cases such changes have significant impact on the state on runtime data structures such that changing the behaviour after the initialization of the core program state isn’t a sound option.

      Do you have an example where that might be a problem?

      1. 5

        Two examples I’m aware of:

        • The allocator being used - after a program has started running you have heap allocated values, so switching the allocator is no longer possible
        • In JSC a bunch of JIT and RW/RX heaps may or may not be set up depending on whether a process is allowed to have a JIT (or rather RWX memory), retroactively changing the mode isn’t possible due to various thunks having necessarily different behavior. JSC has a bunch of other behaviors which in principle you could toggle, but it would be complicated (things like multithreaded GC and JIT compilation - in theory you could do a thread join to collect all the relevant threads and have them terminate, but that would add a runtime cost to those threads).
        1. 2

          Ah, I think I see–it’s the difference between using “Feature flags” as a specific term of art, vs. just being a general “flag” that controls a “feature”. Language and communication is always interesting, at least.

    2. 3

      The overengineering in the first article is justified by the desired feature in the second article. The original flag manager could be simpler, but its API could easily be extended to add feature-flag mutation at runtime.

      Feature flags shouldn’t be mutable at runtime, especially in containerized/isolated systems. When flags are mutable, the number of possible microstates of the system is doubled for each flag. For example, given a daemon with one feature labeled “off” or “on” and one mutable flag toggling it, we have four microstates: started off, currently off; started on, currently on; started off, currently on; and started on, currently off. This exponentially increases the effort required to debug an individual instance.

      1. 3

        I think that there’s a few things that mitigate the complexity risks involved:

        • They tend to be used at the leaves of the system, eg: whether you’ll be opted in to a new version of a user experience, or similar.
        • Once you’ve learned what you need from the flag (eg: that it’s been rolled out to 100% of customers and everything’s been happy for a week) you should be going back and removing them. (Granted, many organisations seem to forget this vital step).

        You’re definitely correct that if you have multiple interacting feature flags at once you deserve what you get.