Your Might Be Running A Thousand Applications

Feature flags are awesome. But just like user preferences or settings they have the tendency of turning your application into multiple applications, all embedded in one.

A feature flag is a bit (an on/off switch), and for any given user, it can be either on or off. But it helps to be mindful of the following: the number of possible states of any given user is actually a product of all your feature flags. There is a handy formula for calculating the total number of possible states your application may be for any given user depending on the feature flags being on or off, and it goes like this:

2 ** num_feature_flags

(** is “raised to the power of” in Ruby-speak). So, if your application has 10 feature flags: congratulations, any user might be running nog the application you are building and testing, but one of its 1024 different variations. This leads to a combinatorial explosion of things you need to test, and worse even - to feature interaction bugs. If your development process is very rapid, it will not take long before everyone just gives up testing everything in every combination of the feature flags, and some bugs will invariably seep through.

It is not all doom and gloom, however. Here are the rules that I follow to reduce the potential blast radius of those things:

• Use feature flags either “all the way left” (in some high-level module at the start of any given user flow) or “all the way right” (at the deepest call site). Definitely not both and not “in the middle”
• Try to localize feature flags to one domain of the application. If it has to do with checkouts - do not use the feature flag anywhere except within checkouts
• Delete feature flags at the earliest opportunity

I don’t subscribe to the notion that feature flags bring ruin - they are an excellent tool. Just be mindful of the power factor.