Not Everything Can Be Feature Flagged

Once you begin weaving feature flags into your product development life-cycle, it can become hard to imagine any other way of working. But, not every type of change can—or should—be put behind a feature flag. Sometimes, the level of effort isn't worth the added complexity.

At the end of the day, anything is possible when given the necessary time and resources. But, not everything is worth the cost of implementation. Feature flags should be relatively easy to use—they should be simplifying the amount of work you have to do in order to make changes in a production application. If the path forward isn't clear, it's possible that the change you're making isn't a good match for feature flags.

And, that's OK.

Feature flags are a tool. You use them when they make sense. And, you choose another tool when they don't make sense.

In my experience, feature flags are most effective for localized changes. That is, when the changes live within a relatively small boundary. Feature flags become less effective when the changes have broader implications or require many files to change simultaneously.

Some examples of work that doesn't play well with feature flags:

• Updating a database version. Not only does updating a database require downtime for your application, version changes can have knock-on effects for every single query in your application. Attempting to branch the logic of every single query is an extraordinary cost that's likely to create bugs, not prevent them.

• Updating a JavaScript framework. If you're updating a JavaScript framework without making any other front-end changes, you might possibly gate the <script> tag behind a feature flag. But, if your JavaScript framework has any breaking changes within the update, those breaking changes can have knock-on effects that live anywhere in the application. Trying to gate both the version of your framework and the affected front-end code is going to add massive complexity.

• Updating a CSS framework. CSS doesn't exist in a vacuum. It works in conjunction with HTML (and can often act as a hook for JavaScript DOM queries). Which means, when you change the CSS in a large refactoring, you often have to change a lot of your HTML structure as well. Trying to gate both your <link> tag and the affected front-end code is going to add massive complexity.

• Updating your application runtime. Feature flags operate within your application runtime. As such, they can't be used to determine which application runtime is currently operating.

Any change that touches a lot of files or has implications for many files is not worth the effort (in terms of feature flags). Feature flags are amazing; but, they're not a panacea. For this type of work, you'll have to continue using whatever strategies you've been using historically.

Have questions? Let's discuss this chapter: https://bennadel.com/go/4554