Using Feature Switches for Code


Using feature switches fore code development is a technique used by software developers or DevOps professionals to turn portions of code on or off without requiring a rebuild of the application.  There can be many reasons for using this technique. Often, a feature may need to be released but is in the same build as a feature that cannot be released.  In other cases important code releases require customer notification that may not have happened yet.  Releasing the code with the ability to turn certain features off can clear it as a work item for the IT team while leaving the business with the flexibility to release the feature at a later date.

Feature switches for the Clearent back end development team typically come in two parts: a configuration setting indicating the state of the feature and a dependency swap or IF statement to switch the behavior out based on the configuration setting.  Here is a simple example of what a feature switch could look like:


<add key=”EnableNewPricingOptions” value=”false” />


if (ConfigurationManager.AppSettings[“EnableNewPricingOptions”] == “true”)
return new NewPricingOptions();
return new OldPricingOptions();

The previous example would likely need to be associated with some official marketing statement or promotion that could derail a team’s ability to ship bug fixes or other features in the interim.  A feature switch allows the team to have the code ready early and ship on their own schedule while limiting access to the new functionality.  Once the code is enabled in production the feature switch would be removed and the old code deprecated or pruned.

Feature switches can come in a number of forms.  Most frequently we find that a boolean switch, like the previous example, is sufficient.  But the trigger for enabling a feature can be in the form of a date when the feature should be activated or a numeric value, such as a timeout or minimum amount that takes effect only when the value is not zero (shown below).  Although we often don’t see it this way, user permissions can also be a feature switch.  At Clearent, we often roll out new functionality but only give permissions to a handful of users until we’ve had a chance to make certain that it functions well in the wild.  We can then roll the new feature out to other users confidently.  In rarer instances, we roll features out to one but not all of our datacenters and try out a feature on an isolated set of servers before enabling the feature everywhere.


<add key=”NewPricingEffectiveDate” value=”4/15/2016″ />
<add key=“MaxUserWaitTime” value=”5″ /> <!– in seconds –>

This flexibility comes at the cost of complexity.  While our deployment and development process is simplified, the testing burden is increased.  Cyclomatic complexity, the measure of the number of paths through the code, is also increased.  Feature switches develop a Schrodinger’s cat type of quality.  For the time that the switch is in the codebase it must be thought of as both on and off.  Testing must take into account the fact that the system may go live with the feature enabled or disabled and both scenarios must be tested.  In cases where the feature is significant enough to warrant a switch the testing burden can be large.

At Clearent we work with every major card brand.  As each card brand evolves with new features and products, we have to make changes to our payments platform well in advance and be ready when the functionality is enabled for card issuers.  While some features are home-grown, our code has to be ready when our partners are which means testing and releasing code early and being able to pivot quickly when the time comes.  We reach for feature switches frequently to keep our development practices agile and respond to timelines that work better for our partners and users.