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:

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...