4 ms·

They can be all kinds of things, at its most basic, its just a way to put features behind some kind of toggle, that are only shipped or enabled if something is

They can be all kinds of things, at its most basic, its just a way to put features behind some kind of toggle, that are only shipped or enabled if something is determined to be toggled as "on". For example, you can use `#ifdef` in some languages like C#, C++ and C to provide features based on platforms and/or language versions, so builds only contain code when those statements are true. With things like esbuild, webpack, or vite, you can use their `define` options or in the case of webpack, something like the `DefinePlugin` or `EnvironmentPlugin`, to turn `process.env (like `process.env.NODE_ENV` etc) or other synthetic globals to certain values, which enable features (and ideally, tree shake out unused ones for the build). These are typically done and used at build time. These can also be done at runtime, by either hardcoding a feature behind some kind of statement to evaluate its usage, or using more sophisticated feature flagging systems, such as: - Split IO[0] - Launch Darkly[1] which let you toggle the feature flags dynamically during runtime. This is how you can do things like A/B testing, for instance, or allow only certain users access to a feature. These are the most common examples of feature flagging I can think of that I think most have seen, even when its not explicitly noted as such. I'm not entirely sure that gating vs flagging should be defined differently Note: I have zero affiliation with either of these products I mentioned, I've just used them before [0]: https://www.split.io/ https://www.split.io/ [1]:https://launchdarkly.com/ https://launchdarkly.com/

e28eta 5y ago
> I'm not entirely sure that gating vs flagging should be defined differently I think it’s interesting to contemplate. I think they’ve both stuck around at Stripe for so long because there’s something useful communicated by the (correct) choice, and having different implementations with different trade offs based on the use case. OTOH, every single user of the system has to understand the differences in order to consume them correctly, and even the search/browse is (was?) separate, iirc. I suspect a big improvement would just be to unify the web administrative interface: clearly indicate which is which, but allow common operations without needing to know ahead of time whether something is a flag or a gate.
shoo 5y ago
A flag function that decides a boolean decision could have a signature such as f: context_t -> bool where context_t is a value type containing fields such as: uuid of the current user, uuid of the node or region we are deployed to, the current time, the current version of the application code. Feature flag platforms such as launch darkly can be thought of as a way to manage and deploy new implementations of decision functions into running application processes. E.g. dream up a class of decision functions with the signature f: context_t -> bool that could be serialised and sent over the wire between two machines. For large muddled IT organisations, toggling a flag in a production application by having a developer hardcode it or toggling a flag by changing static application config and redeploying might require 15 minutes of development time followed by days of integration testing and meetings and change approval lead times. In these settings, having some kind of feature flag platform deployed that allows application behaviour to be toggled very rapidly without coupling it to some kind of IT software deployment might let the organisation react and run experiments two or three orders of magnitude faster. Give product managers or "the business" the ability to adjust application configuration live in production with the feature flags without having layers of slow process in the way. If your application contains a large subsystem where some decision or logic is evaluated by a pure function, it might be a fun exercise to think through "what if we made that it possible to swap in new implementations of that function into a running process in production, like a feature flag". E.g. if your subsystem can be described as an one big expression tree, and there's a way to serialise that expression and send it over the wire, and have an interpreter in your application process execute it. Maybe the natural and logical conclusion to this is that every production application should be Joe Armstrong's universal server: https://joearms.github.io/published/2013-11-21-My-favorite-erlang-program.html https://joearms.github.io/published/2013-11-21-My-favorite-e...
grammarnazzzi 5y ago
> I'm not entirely sure that gating vs flagging should be defined differently I think that's the point of the article. "feature flags" = "gates" = "circuit breakers" = "knobs"? really? > This was a problem especially for newer engineers, who would get (unsurprisingly) confused as to whether they should be using one or the other, and even senior engineers would regularly forget that the flag they’re looking for is actually a gate (happened to me five times a week). Ideally, these would be just be one concept That's what you get when you try to be clever with your vocabulary rather than using longer and less ambiguous terms

e28eta 5y ago

> I'm not entirely sure that gating vs flagging should be defined differently I think it’s interesting to contemplate. I think they’ve both stuck around at Stripe for so long because there’s something useful communicated by the (correct) choice, and having different implementations with different trade offs based on the use case. OTOH, every single user of the system has to understand the differences in order to consume them correctly, and even the search/browse is (was?) separate, iirc. I suspect a big improvement would just be to unify the web administrative interface: clearly indicate which is which, but allow common operations without needing to know ahead of time whether something is a flag or a gate.

shoo 5y ago

A flag function that decides a boolean decision could have a signature such as f: context_t -> bool where context_t is a value type containing fields such as: uuid of the current user, uuid of the node or region we are deployed to, the current time, the current version of the application code. Feature flag platforms such as launch darkly can be thought of as a way to manage and deploy new implementations of decision functions into running application processes. E.g. dream up a class of decision functions with the signature f: context_t -> bool that could be serialised and sent over the wire between two machines. For large muddled IT organisations, toggling a flag in a production application by having a developer hardcode it or toggling a flag by changing static application config and redeploying might require 15 minutes of development time followed by days of integration testing and meetings and change approval lead times. In these settings, having some kind of feature flag platform deployed that allows application behaviour to be toggled very rapidly without coupling it to some kind of IT software deployment might let the organisation react and run experiments two or three orders of magnitude faster. Give product managers or "the business" the ability to adjust application configuration live in production with the feature flags without having layers of slow process in the way. If your application contains a large subsystem where some decision or logic is evaluated by a pure function, it might be a fun exercise to think through "what if we made that it possible to swap in new implementations of that function into a running process in production, like a feature flag". E.g. if your subsystem can be described as an one big expression tree, and there's a way to serialise that expression and send it over the wire, and have an interpreter in your application process execute it. Maybe the natural and logical conclusion to this is that every production application should be Joe Armstrong's universal server: https://joearms.github.io/published/2013-11-21-My-favorite-erlang-program.html https://joearms.github.io/published/2013-11-21-My-favorite-e...

grammarnazzzi 5y ago

> I'm not entirely sure that gating vs flagging should be defined differently I think that's the point of the article. "feature flags" = "gates" = "circuit breakers" = "knobs"? really? > This was a problem especially for newer engineers, who would get (unsurprisingly) confused as to whether they should be using one or the other, and even senior engineers would regularly forget that the flag they’re looking for is actually a gate (happened to me five times a week). Ideally, these would be just be one concept That's what you get when you try to be clever with your vocabulary rather than using longer and less ambiguous terms