In the same way that organizations can increase the number of users who see a feature, they can also decrease that number to zero, creating a kill switch. This capability comes in handy when a feature doesn’t behave as planned. Developers can roll back the change and let life go back to normal for users without redeploying and emergency patching. It’s also useful for sunsetting and then decommissioning legacy features. Kill switches absorb much of the risk, stress, and overhead from a release for developers as it’s simple to roll back a feature. This in turn gives them more confidence to experiment and work faster to create features!
Feature flags provide a safe method for shifting a level of testing to production, from infrastructure testing to user acceptance testing (UAT). Even the best pre-production test environment cannot perfectly mirror the dynamics of production, and pushing code straight to production in a safe, partitioned way that does not impact the rest of users allows QA teams to get a realistic view of how a feature will perform in production without worrying about creating every possible scenario in a pre-production test environment. This greatly reduces the risk of a release once all users have the feature.
Feature flags provide a low-risk alternative to the forklift upgrade of years past that often ended in fire drills. Rather than rewriting large swaths of code for a one-time migration that causes issues, developers can use feature flags to start building calls to the new service or database directly into the existing application. Then they can discreetly test out the new connection at a more secure time to see if it’s working. When it is time to completely migrate, the code will have been in production for a long time and flipping the switch will be a non-event.