3 ms·

This is a classic "sounds easy but is actually a bit tricky" situation. What if you have 1m LoC and 5k feature flags covering features over a 6-12 month develop

This is a classic "sounds easy but is actually a bit tricky" situation. What if you have 1m LoC and 5k feature flags covering features over a 6-12 month development cycle? What if you have a combination of "serverless" cloud stuff and long-running server apps? What about feature toggles on the client side, or in your GraphQL layer? What if you have applications multiple programming languages? Etc etc. As with a lot of things in programming, returns to scale actually go negative after a certain size.

vouwfietsman 5y ago
I think the confusion here is that traditionally a feature flag is part of the source code, or potentially deployment configuration. Not something that should be modified during runtime of production code, but only during deployments/releases. It seems that the modern interpretation is much more fluid, where a feature flag can be toggled on and off during runtime over multiple services. It seems logical that you would then want a "command and control" API that flips these things on a larger scale. However, to me this still sounds very strange. If you have 5k feature flags, do you really have any idea of what is running at all, at any time, anyway? What if you get a bug ticket from last week? Is there such a thing as a "deployment" if the code you execute is dependent on 5k bits that can be flipped and alter execution at any time? If you really need this much runtime configuration shouldn't it be part of some admin workflow that is just inherent to your application? Why would you even risk synchronizing another piece of state over a distributed system that alters the code? Wouldn't you want this stuff to just be part of your data model? Seems its no longer about feature flags, but about having a global table of bits you can abuse from any and all elements of your architecture, as a shortcut to actual good data design.
- nerdponx 5y ago
  As an addendum, I think it's very unlikely that any one team is concerned with a large number of feature flags at any given time. But if you have multiple teams working on different parts of a big application, complexity starts to add up.

vouwfietsman 5y ago

I think the confusion here is that traditionally a feature flag is part of the source code, or potentially deployment configuration. Not something that should be modified during runtime of production code, but only during deployments/releases. It seems that the modern interpretation is much more fluid, where a feature flag can be toggled on and off during runtime over multiple services. It seems logical that you would then want a "command and control" API that flips these things on a larger scale. However, to me this still sounds very strange. If you have 5k feature flags, do you really have any idea of what is running at all, at any time, anyway? What if you get a bug ticket from last week? Is there such a thing as a "deployment" if the code you execute is dependent on 5k bits that can be flipped and alter execution at any time? If you really need this much runtime configuration shouldn't it be part of some admin workflow that is just inherent to your application? Why would you even risk synchronizing another piece of state over a distributed system that alters the code? Wouldn't you want this stuff to just be part of your data model? Seems its no longer about feature flags, but about having a global table of bits you can abuse from any and all elements of your architecture, as a shortcut to actual good data design.

nerdponx 5y ago
As an addendum, I think it's very unlikely that any one team is concerned with a large number of feature flags at any given time. But if you have multiple teams working on different parts of a big application, complexity starts to add up.