In last few years we all have observed a steady increase in number of changes going into production. Every software application is changing at a rapid rate. Businesses & Applications are in a change fast or perish faster kind of a state. For a software engineering team all stakeholders are getting more and more demanding. We are identifying more and more ways to increase our ability to deliver change faster and cleaner. Agile, DevOps, cloud, CI/CD, etc. are all ways to make ourselves faster at delivering.
Developers from every discipline, be it from waterfall or agile has experienced the pain of changing requirements. To support such changing requirements the concept of Feature Toggle was invented. It is not new; However, in the last couple of years, I am seeing its usage has increased and is being discussed a lot.
Feature toggles enable one to toggle between features on the fly or with a restart. The toggle switches can be in application’s configuration files or persistently saved in a database. It’s a very good way to manage fast high-risk changes or long-running changes.
Below are four common use case of feature toggles:
Use case 1:
Say in an agile project we are implementing a complex capability. We know that complete development will take a long time. Probably multiple releases of the software will go into production during this time. As we are incrementally building this functionality, we want these changes to be tested by QA/Business teams to get early feedback. However, we don’t want the code to run in production. To support this, we are merging the code into our development branch. There we run our unit and component tests. And finally, they get merged into our release branch; this goes well with our continuous integration theme.
So the partial feature resides in our release branch and gets deployed in the test environment. Where the partial functionality gets tested. Additionally, we create a config entry taking a boolean value that will let the application know at run time whether to run the code or not. In the software, it is a matter of reading the value from the config at the start and using it to decide whether to execute the new functionality. We need to have the toggle switch turned on in test environments and turned off in prod environments.
Till you find an automatic way to toggle the feature based on environments, the team must remember to check-in a false value in the config while packaging for production. The other way would be to keep the value set to false all the time. Let someone change the configuration before they want to test the functionality. Both options are equally painful.
The team should spend some time to find a way to automatically toggle based on environments. This would eliminate a lot of unwanted situations in test and production; like forgetting to enable the feature in the test or disable the feature in production. Believe me, anything that can go wrong will eventually go wrong.
Use case 2:
While developing new functionality, at times business will not able to decide on things. Maybe they are looking at multiple things to decide on an action; like they need to reconcile data from multiple systems (internal or external) and come up with a conclusion. These things take time. Sometimes the data is not enough to correctly conclude. But a requirement has been placed and the development team is developing it. Everyone understands that the requirement may change at any time.
For such requirements having a toggle switch would be appropriate. In case, business decides to hold off the change at the last minute; a feature toggle can save you from another deployment. Post-deployment we just need to turn off the feature.
Use case 3:
Say the release will happen on day 1, but a particular feature is required on day 15. May be this is due to some external dependencies. In such case, feature toggles come handy.
Use case 4:
Say a a bug got introduced with the new feature. It works correctly most of the time as the code passed your unit test, the QA test and acceptance test. However, there is an edge case missed by everyone. Once identified, the feature can be turned off till its fixed through next deployment.
Pitfalls
A word of caution: There can be an explosion of feature toggles within a very short period of time. Especially if feature toggles are not removed once they serve their purpose.
Once stakeholders responsible for creating and defining requirements understands the concept of feature toggle, they may ask to implement feature toggle in every new feature/requirement. It’s like having a jail free card; anything goes wrong we turn off the new functionality without the need to revert or deploy an immediate fix. One will argue that it is not a bad idea, but this practice will lead to feature toggle’s explosion in your configuration file.
Like every other thing there are pitfalls of over use. A feature toggle’s explosion will make the configuration very hard to read. One will have to think of multiple what-if situations because of multiple feature toggles. You are not sure of which functionality you can depend on.
If you start using feature toggles, dedicate some time to remove old feature toggles that are not in use anymore.