Feature switches, also known as feature toggles or feature flags, are a powerful technique that allows great control over a software product in a dynamic way. Praised by many important figures in the software development community, including famous Martin Fowler, when used correctly they can greatly improve the way your product is released to your clients, the importance of the features is confirmed among your users, and the whole system could be stabilized.
What are feature switches?
In short, a feature switch is a logical condition mechanism that allows to turn on and off some feature of your product. That can be, to give an example, switch enabling or disabling an e-commerce feature your team has been working for a long time. Your team has spent weeks on that feature, but you don’t want to show just a final effect, not some not-so-final iteration, right?
Here’s where a feature switch can be very handy – with just flipping one condition you can enable e-commerce solutions for all your users, at the same time, when it is ready.
However, the importance of feature switches goes beyond that. There are at least a few more good use causes when a feature switch can be very helpful. Let’s cover some most common use cases.
Releasing to production
As described above, with a feature switch it is far easier to deliver given functionality to your users. While it might sound obvious, please keep in mind one important condition, especially relevant for mobile and desktop apps: not all users of your app would have the latest version installed. And that definitely won’t happen on the first day after you have released an update.
Getting back to our e-commerce example, let’s say you want to add a shop to your mobile app. The development is finished, everything looks perfect, you have released your app to App Store and Google Play and spend your very own money on a marketing campaign. And all you hear in the first day that people don’t see your product in the app.
That’s because they forgot to press an “Update” button. If they are Apple users, they would see a red dot next to the App Store icon, indicating that an update is available, but still would have to press the “Update” button. Android users would typically get the update installed automatically but within a few days. That’s far from being perfect.
To get back control over the date when a feature is delivered you can use a feature switch. Prepare an update to your apps at least a few days before the big launch date, give that time for your users to perform update. And whey everything will be ready – flip a switch.
That’s, by the way, the technique we are using for the Handcrafted Platform. Each module can be enabled or disabled with a feature switch. You can read more about modules here: https://handcraftedplatform.eu/2020/01/28/modularity-why-it-is-important-for-your-app/
Performing testing & optimizations
But that’s not all you can do with a feature switches. Some common use cases for them include testing changes to your software product among your users. Would a new e-commerce basket mechanism work better than the previous one? There’s a good way to check that, and it’s called A/B testing. Release new mechanism to some of your users, while you keep the old version for the rest of them. Measure how good it is by comparing to the previous solution (most likely you want your conversion stats to be better), and decide if it is really better.
Sometimes you might want to perform similar tests with your features just to observe if it does not have any negative influence on other parts of your system. Say – you are worried that a new friend suggestion mechanism would impact the overall performance of your app. One of the solutions would be testing that with a feature switch and observing the performance stats.
If you are interested in other ways you can use feature switches in your product or want to learn about best practices for including feature switches in your product, you can read a great article by Pete Hodgson on martinfowler.com site: https://martinfowler.com/articles/feature-toggles.html