Managing Feature Flags

Chapter 3. Succeeding with Feature Flags

As highlighted in previous chapters, adding feature flagging capabilities to the code base can provide a broad range of benefits. However, feature flags can also add complexity to the code base and reduce internal quality. It’s not uncommon for teams who have recently embraced feature flagging to feel that they have added some tax to their software system. Code can become littered with conditional flag checks, and it can seem that every part of the code base (and every test) has a dependency on the feature flagging infrastructure.

In this chapter, we look at some specific techniques that you can use to ensure that feature-flagged code is readable, maintainable, and testable. Most of the techniques we discuss are really just good general software design principles applied in the context of feature flagging code. Similar to test code, feature flagging code seems to be treated as second-class code that doesn’t need the same level of thought as “regular” code. This is not the case, as you’ll see.

The Moving Parts of a Flagging System

Let’s define the various moving parts involved in a feature flagging decision, based on the following example decision:

if (flags.isOn("product-images-carousel", {user: request.user})) {
  renderProductImagesCarousel();
} else {
  renderClassicProductImages();
}

Toggle Point

The toggle point is the place in the code base where you choose a code path based on a feature flag. In this example it’s the if conditional ...