Talks Tech #30: Fun with Feature Flags

Women Who Code Talks Tech 30     |     Spotify – iTunes – Google – YouTube – Text

Desy Kristianti (she/her), Senior Frontend Engineer at Prolific, presents her talk entitled “Fun with (Feature) Flags.” She discusses what they are, why we would use them, and how we can implement them successfully within a company.

Why should we care about Feature Flags? When you release a change, you can be confident about it and accidentally introduce new bugs. Or you release a new feature, but the users don’t like it or don’t know how to use it. You could release a change, and something goes wrong, and you need to switch it off immediately or roll it back, but the rollback process isn’t easy or takes a long time. Feature Flags can help in these situations.

Feature Flags enable you to toggle features or functionality without deploying a code change. There is usually an admin or management page where you can see all of the Feature Flags, their status, and whether they are on or off. When you click on or toggle it to off, it will change immediately in the product. You don’t have to change anything in the code.

This is implemented when you develop the feature by wrapping the code inside the Feature Flag. An example will be rendering the new modal if flag ABC is enabled. Else, render the old modal. Feature Flags can have an on-and-off state, but they don’t always have to be Boolean. Suppose you needed three states to show the feature one way for users in America, another for users in Europe, and a third for everybody else. In that case, you could have three states on the Feature Flag, as well as for the on state, and then for the off state, where the feature doesn’t even show up. The Feature Flag can be a numeric flag, with each number corresponding to each variation.

You want to use these during the incremental rollout of a feature. When we roll out a new feature, we usually roll out to 10% or 15% of the users. We enable the Feature Flag for only 10% or 15% of the users and then wait a couple of days to see if there are any bugs, major issues, or major complaints. If not, we continue releasing 30%, 50%, and so on. If you need to roll back or turn it off, you can turn off the Feature Flag, and it will be gone.

They also allow for separate and safe deployment of the front end and back end. If you’re working on a feature as a front-end developer, and the back end is not ready yet, it doesn’t mean that you can’t progress the front end. Sometimes there are parts that you have to muck out in the meantime. Developing under a Feature Flag enables you to merge the PR, knowing that it’s off in production so that nobody will see the incomplete feature.

There are a few third-party Feature Flag management tools that you can use. You can also do it yourself. You would use third-party tools when you can’t build your tool. They enable you to experiment and measure the results of the experimentation.

However, you are also restricted to what features third-party tools have available. If there is something that you need it for, but the tool doesn’t have it, that’s a restriction that you have to work with. Or some features might not be included in the core package, forcing you to pay extra.

You can build it yourself when you have the resources to build the capabilities, and you’re not worried about being able to use them quickly. Another reason to build it yourself is if the tools out there don’t have an SDK for your programming language. There are so many frameworks and programming languages that third-party tools might not have an SDK for all of them. It might also make sense if your product already has an admin tool. You could add another section or page to control Feature Flags, making it less of an investment to build a new tool. However, it does become another product to maintain. That’s a balance that you have to find. Some companies can afford this, while others pay for the external product.

To successfully implement Feature Flags, you must first use unified naming conventions. The name of the feature should be clear. Sometimes there is a description field so you can explain if it’s not clear from the name.

You also need clear ownership and access controls. You have to decide which team owns which Feature Flag. That way, you know which team to go to if there are any issues.

Access control is another critical component. You need to define who has permission to turn it on and off. Use labels or tags to connect them to the page, the feature, or the team.

Temporary versus permanent is very important as well. It will be temporary if you’re using Feature Flags to release safely. At some point, you’ll be confident that the feature is good. A permanent Feature Flag enables you to show different things to different users.

The fallback value is what happens if the tool cannot be accessed. If you’re using a tool and can’t access the value of the Feature Flag at any point in time, you should have a fallback value so that it still shows the correct state. The fallback value isn’t always the false state. It could be that the flag equals true is the default. That’s why you should always set that up in your code.

Test all of the states of the Feature Flag. This is something that I’m guilty of sometimes. I would build a new feature, put it under the Feature Flag, and then forget to test what happens when the flag is off, not realizing that I’ve changed something or put in a new method that runs in both states. Always test both states of the flag or all the states even.

There are challenges to using Feature Flags as well. Maintaining multiple versions of code can be annoying. If the change is significant, it could show one thing in its old state or something else in the new state. There could be methods that need to be changed or CSS classes that need to be changed. You have to maintain both because the off-state needs to work. If a bug arises before you add the new feature, you have to make the fix on both off-state and on-state.

Next, cleaning up old Feature Flags. You can quickly accumulate multiple Feature Flags if you don’t review them, which could add up as tech debt. When the management tool fails and the user is creating something using your product, it could interrupt their flow. It’s essential to set up a fallback variation within your code itself.

Last but not least, don’t just rely on Feature Flags. You should still write comprehensive tests and not just rely on users testing it. You should also still be able to roll back.