I take it that most people, by now, know what Feature Flags are. The interesting thing, though, is that depending on whom you ask, they’ll have a slightly different answer as they have a slightly different use for the flags. The UX designers see them as a way to test users’ responses to various interface choices and flows. Similarly, an advertiser will tell you that they use Feature Flags to test audiences’ responses to different campaigns. For software developers, they are a fantastic tool that helps maintain a high pace of development, allows the developers to follow CI/CD practices, and still allows them to control when and how the changes go live.

At their core, Feature Flags are just like if-conditions, the result of which can be controlled without changing the code! Not all if-conditions are feature flags, and not all changes can be bounded by feature flags.

Broadly, the changes we make to the product can be categorized into three types:

1. Bugfixes. A bug is a deviation from the expected behavior of the product, and a bugfix is a change to make to the code to bridge this gap. These tend to be minor changes.
2. Additions. These should include new feature enhancements, generally more significant changes that tend to need their configuration.
3. Changes to default behavior. These are where the user’s experience changes without any action being taken or a setting being changed themselves. These are of a broad category, and these are the changes where feature flags help. Interestingly, one can also categorize the addition of the configuration options for the additions-type change into this category!

Although this is addressed to some extent by the categorization above, one can note the similarity between a configuration option and a feature flag. The difference would be that the feature flags will be removed once the test is complete or the changes are live. They have a limited lifespan. Secondly, they can be flipped, preferably through an admin panel, for the entire or a subset of the user group.

Moving on to the changes that cannot / should not be controlled by feature flags, try managing a table structure or the output of a background batch this way! The farther we move from the front end of the software, the harder it becomes to control the features this way. When it comes to tables and batched reports, one needs to execute both implementations and show the applicable one based on the state of the feature flag. The feasibility of these solutions will depend on the complexity of the approaches and the availability of resources! But this is a concern one needs to tackle in trunk-based development.