Feature Flags and Feature Toggles: A Strategy for Controlled Rollouts

  • 18 September 2023
  • 2 replies
  • 81 views

Userlevel 6
Badge +4

The topic of "Feature Flags and Feature Toggles: A Strategy for Controlled Rollouts" is a valuable discussion point for developers interested in optimizing their release processes. 

 

What are Feature Flags and Toggles 

Feature flags (also known as feature toggles) are a development technique that allows you to turn specific features or parts of your application on or off at runtime. They are essentially conditional statements in your code that determine whether a particular feature should be visible or active for end-users. This enables developers to have granular control over feature releases and updates.

Do you use features flags?

What is your experience with them?

Any benefits/drawbacks that you want to share?


2 replies

Userlevel 3
Badge

This is an interesting question, because feature flags have such a broad scope. The only time I’ve seriously or consistently used feature flags for was in a previous position as a support engineer, and they were a great solution for pain points or bugs that were context-specific to various users. 

The thing is, feature flags cover so many different scenarios, it’s hard to simply call them “good” or “bad” as a whole. I know in my case, there were instances in which they were incredibly useful and worked perfectly as a quick solution to a user’s problem (iframe support, adblocker recognition, adjusting visual preferences on a website), but in other cases feature flags were somewhat obscure, or activated without any identifiable impact, or caused conflicts with the end-user’s environment. 

And that leads to what I would consider the only major, or perhaps problematic drawback: familiarity. If you’re not the developer or individual that created the feature flag, you don’t know exactly what’s going on in the code when you switch a flag from off to on. Something like a visibility: hidden; CSS modification probably isn’t going to cause much harm, but what if a colleague activates a flag that triggers a subtle script? Particularly if you were never informed that it was activated? It’s obvious how feature flags can be relatively harmless on one end of the spectrum all the way to project halting on the other. 

Overall, I’d said I’m a fan of feature flags, since they allow for some quick, relatively low-risk solutions to problems. Again, this was in a support role- I haven’t actually used feature flags in the context of development directly. I think the key is to 1. make sure your colleagues, employees, or whoever has access to flags knows what they’re doing and what flags are capable of, and 2. ensure you have a system of keeping track and/or being aware of what feature flags are and aren’t activated. The moment you become blind to who’s doing what in an environment, you’re opening up the door for headaches. 

Userlevel 5
Badge +3

Do you use features flags?

Have done in the past, but maybe only in 2-3 projects

What is your experience with them?

Useful in certain situations only. They make sense if:

  • an environment limitation exists and workarounds such as service virtualisation cannot be used
  • a product functionality is added only for beta testers but shouldn’t immediately be available to all 

These are the only situations I’ve personally experienced

Any benefits/drawbacks that you want to share?

It’s extra testing effort for the testing team in addition to the great points posted above. You’re not then testing 1 product, but states or versions of it, so akin to 2 products at the same time. For the later example, testing who should & shouldn’t have access is an extra + potentially time consuming headache to test.

Reply