In software development, a kill switch is a button that disables a feature if needed. This enables stakeholders to turn off broken features in production simply and immediately, which is often accomplished via a feature flag. Before feature flags, if something were wrong, developers would have to look through the logs, pinpoint the issue, analyze how to fix it, write the code fix, test it, and then push it live to production, all while the feature is broken in production.
Incident Management Made Easy With a Kill Switch
With a kill switch, when a feature breaks in production, you can turn it off immediately while your team analyzes the issue. This is ideal, especially when you get paged in the middle of the night and find yourself less than eager to take on a code fix. Having a kill switch allows you to quickly disable the feature, then work on a fix at your leisure, and push it when ready, rather than working under pressure to fix a production issue. Not only is this great to promote a good engineering culture, but it also allows anyone on the team to control the state of a feature, regardless of if they code.
If there is an issue with your code, you won’t have to go through an entire code review process or revert the change that caused the problem. All you’ll need to do is log in to the feature flagging framework and click on the kill switch for that feature.
Isolate Code Changes
Let’s take an example of a typical agile team using feature flags in their software development lifecycle. Once the team deploys the code to production, and the product owner turns the flag on, then based on your configuration, the entire user base, or a subset of the user base will be able to see and interact with the new feature. However, in a few weeks, if something goes wrong and there is a bug with the new feature, what do you do?
In this way, you avoid rolling back an entire version of your application because you isolate the change to a specific feature. This also allows development on other features to continue without forcing a complete rollback. In effect, you’re isolating the change while your codebase evolves around it.
The Cost of a Kill Switch
Any additional implementation to your codebase comes with a cost. Kill switches are no exception. The first cost is the management cost. To maintain a codebase with feature flags, you must continually be aware of the different flags’ states. If not, you will likely be overwhelmed with the sheer volume of flags and unable to maintain them properly. There is also a code cost. The more extra code you add to your codebase, the more complex it gets, and the harder it gets to reason about that code. There is also a testing cost that comes with testing each new feature and all its different variations. With all of that in mind, the benefits clearly outweigh the cost.
