How Feature Flags Tame the Four Heads of Complexity

Complexity in software testing can feel like a four-headed monster, feature flags can tame this beast.

Explaining feature flags in economic terms can be difficult. Recently though, I was struck by a post written by Kent Beck where he explains Facebook’s extreme programming culture in easy-to-understand terms. After reading it, I realized that that same terminology could be used to describe feature flags, seeing how Facebook’s deployment structure and feature flags are one of the same.

A New Type of Beta-Testing

In case you don’t know, feature flags make testing software easier. It’s a form of dark-launching, where developers stealthily deploy new features without upsetting the balance of the product or application. You can even roll out a new feature to a certain group of users and exclude others, in case you want to test it in a controlled setting. If said feature upsets the balance, then you can easily retract the feature with a press of a button. No harm, no foul.

The Four Heads of Complexity

Now, in Beck’s example, he describes complexity as having four heads. Complexity is the enemy in any system, especially in a tech environment, where one deployment can cause everything to break. If you don’t learn to control this complexity, the system will continue to fail. In order to control complexity, you need to know how to combat each head (this is my paraphrasing of Beck’s example):

States — There are multiple elements in a single state, and there are many states in a single system. It’s hard to maintain each element in each state, and remember what each one is doing within the state.

Interdependencies — The way elements can directly and indirectly affect each other in a state. If a new state is introduced to a system, it creates a larger number of interdependencies.

Uncertainty — This is never knowing when the state is going to blow. Will the application still be running efficiently in the morning?

Irreversibility — The impossibility or difficulty to reverse a state after it’s been changed. If you’re afraid to change something because it may break, then the fourth head of the beast is controlling you.

Combatting Irreversibility With Feature Flags

Feature Flags tame the Irreversibility head of complexity. They make decisions reversible, which quells the uncertainty of upsetting interdependencies in a system of states. Developers can deploy a feature, see what happens, and then change it back if it doesn’t work well. There is less uncertainty with feature flags. If a company wants to test users’ susceptibility to a new feature, they can soft-launch to a small set of users to scale interest. It could also inform developers of the possible interdependencies in a system before an even larger launch.

The best part: developers get validation early. They don’t have to wait eight weeks testing a feature only for it to fail. They can test it early and forget about the complexity beast completely.

Taming the Four Heads: Multivariate Feature Flags

Feature flags generally manifest in two forms: Boolean and Multivariate (a type of feature flag that can serve strings, number, and JSON variations in addition to Boolean variations). This allows users to customize two or more variations of a feature before rolling it to a system. They can decide percentages as well. For instance, they can decide that 10% will get one version of the feature, 20% will get the second, and 70% could get the third version. Through these methods, developers gain more control of their product and worry less about the ugly heads that could appear in the process.

It’s fun to apply the four heads of complexity to other areas of software development as well. It can even be applied to our everyday lives. Of course, you can never truly control complexity in a system, but you can tame it. The whole idea can lead to interesting questions. It makes you ask yourself, how am I combating the complexity beast in my own system?