Feature toggles allow teams to modify system behavior without changing code by using a binary condition to control whether a feature appears in an app. They can be configured in different ways like hardcoded, through parameters, or in a database. There are different types of feature toggles like release toggles for new features, operational toggles for operations, and experiment toggles for A/B testing. When implementing feature toggles, the best approach is to remove conditionals, strategically create objects with dependencies injected, and encapsulate toggle logic in a routing layer to avoid coupling code to the toggle system and proliferation of conditionals. It is important to keep the number of toggles low and remove unused toggles.

1. Feature Toggles
Minni Arora

2. Introduction
Feature toggles are a powerful technique, allowing teams to modify system
behavior without changing code.
It is a binary condition that controls whether a feature appears in the app or not.

3. Example
Feature
Toggling
context
Toggle
configuration
Toggle
router
function apply() {
if (featureIsEnabled("newApply")) {
return applyWithNewAlgorithm();
} else {
return oldFashionedApply();
}
}
Toggle point

4. Categories
● Release toggles
● Operational toggles
● Experiment toggles
● Permission toggles

5. Configuration Management
● Hardcoded
○ // return applyWithNewAlgorithm();
○ return oldFashionedApply();
● Parameterized: command line, environment vars
● In files
● In database. Accompanied with admin UI
● Distributed: zookeeper, etcd, consul etc...

6. Implementation

7. Harcoded
❏ Rigid
❏ Requires manual intervention
❏ Can’t be automated
❏ Error prone
❏ Requires redeployment
class Apply {
………..
// return newApply();
return oldApply();
}

8. Point Toggles
class Apply {
……….
// fetch config from somewhere
………..
if(config.newApply) {
// go to new apply
}
else {
// go to old apply
}
}

9. Point Toggles
❏ One feature, many toggle points
❏ Decision point coupled with decision logic
❏ Messy code that is difficult to maintain
❏ Lacks separation of concerns
❏ Difficult to incorporate toggle scope
changes
class Apply {
// fetch config from somewhere
……
if(config.newApply) {
// go to new apply
}
else {
// go to old apply
}
……
…...
if(config.newApply) {
// do something
}
else {
// do something else
}
……..
}

10. Indirection
❏ One extra concept that Apply is aware of
❏ Coupling with an extra module
❏ Can’t think of Apply in isolation
❏ More and more modules get coupled with
feature toggle system
❏ Feature toggle system becomes a global
dependency
❏ Unwanted proliferation of conditionals
class FeatureDecisions {
// fetch config
public void isNewApply() {
return config.newApply;
}
}
class Apply {
// read isNewApply() from FeatureDecisions
if(isNewApply()) {
// go to new apply
}
else {
// go to old apply
}
}

11. Remove conditionals
❏ Strategic creation of objects
❏ Dependencies injected
❏ Easy to add and remove toggles
❏ Apply is unaware of feature toggle system
❏ Encapsulates if/else statements into the
routing layer
class FeatureFactory {
…...
if(featureDecisions.isNewApply()) {
new Apply (new ApplyWithNewAlgo());
}
else {
new Apply (new OldFashionedApply());
}
}

12. Keep inventory low
● Remove toggles that are no longer needed
● Remove dead code
● Limit the number of toggles
● Don’t create technical debt

13. Thank You
https://martinfowler.com/articles/feature-toggles.html