The rise of internet made it extremely easy to deliver software updates to our users.
You can even upgrade a whole car and fix issues causing random fires without anyone visiting dealership.
Sounds awesome, right?
Yet a lot of us still struggle with releases and panic when they even hear this word.
Developers and Ops Engineers stay late at night and put out the fires that happen when a whole lot of users get access to new parts of the system. Not to mention testers and managers trying to figure out how to organize their work to make sure that what goes live works.
Today, I’m going to tell you a bit about a technique that’s extremely simple to implement and that gives you a lot of control over what’s released and how it’s released.
But first, let’s think what really hurts us when doing a release.
Teams of more than a single person need to find a way of working on the same piece of code simultaneously.
Modern version control systems let us create our own branches out of the mainline code. At first this seems like an elegant solution, but over the years the community learned that it only leads to another problem - merging these branches.
One of the XP practices states that it’s important to merge changes as often as possible.
Easily said, how do you merge features that aren’t finished and shouldn’t go live yet?
In the end, people just stay with long-lived branches and integrate just before the release. And that hurts.
From average developer’s perspective this isn’t important.
Press releases? Huh?
The sad truth is that there are people out there who use our products. And this world cares about timing, way more often that you’d expect.
A good example here is financial software. Taxation rules change year by year.
If the product we’re building needs to cover them, we need to prepare for the new year and apply these changes precisely when the new taxation laws come into effect.
This leaves us with a new feature that needs to be prepared in advance, but not released. Now how to test it and make sure other features that are released in the meantime won’t break it?
Other examples include ed-tech companies that want to release features at the beginning of a new school year or companies launching huge new features with a lot of fanfare and press releases.
Finally, enterprise software projects may bump off release schedules. For instance, the current strict process may allow releases only once a week on Wednesday. If for some reason a feature needs to be released exactly on Monday, how do we do that without breaking the rules?
In the worst case scenario, releasing a feature that’s counterintuitive or doesn’t serve its users can ruin our product’s reputation.
Instead of making bets, it’s great practice to let a group of trusted users test new features first and gather feedback.
If it’s positive we can move further and release it to everyone, and in the opposite case iterate over it or simply kill it.
Running such experiments is often planned and executed by Product Managers, so it’s great if they can take full control over it.
All You Need Is a Toggle
Let’s step back for a moment and think about the simplest common denominator to all of these problems.
In all of these scenarios, what’s helpful is an ability to change the way the application works without making any changes in code or redeploying the application.
This way, we could hide unfinished features or enable them only for certain users. And the release (don’t mistake it for deployment) could be performed by people that aren’t familiar with programming or unix shell.
What we need is a simple toggle.
In his article, Pete Hodgson describes feature toggles as a set of patterns that can help a team deliver new functionality to users in a rapid but safe manner.
Let’s think about the first pain one more time.
We want to merge developer’s changes as often as possible. Features that aren’t finished yet can still be deployed to production, but not accessible to users.
In order to achieve that, we’ll introduce a simple toggle (on/off) for each of these features.
Its state will be saved in a database, so that it can be changed without restarting the application.
Then, depending on its state, we’ll either show it to the users or not. Simple.
On top of that, we’ll need a really simple “command center” that will be accessible by administrators. It will allow people to easily change the status of the toggles and to see what their current status is.
This may sound optional, but we don’t want anyone to do manual changes in the database.
Once that’s done, the workflow is as follows: new features are developed and deployed, but disabled toggles prevent users from even knowing about them.
If possible, that should be done on the UI level, to keep things simple.
Once we feel like a particular feature is ready, all we need to do is to click an “ON” button in our command center.
No more merging and testing at the last moment - everything’s already been in production for a while.
The toggle doesn’t need to have only two states. Depending on various factors (like the kind of product we’re working on or the way we release features) we can expand this idea to adjust it to our needs.
As I mentioned before, one of the things that I’ve noticed happening quite often is testing the newly created feature with a selected group of users. In that case, we can simply add an intermediate state of “selected users only”.
Another common uses case is A/B testing. When testing if the improved version of a feature works better for users, we may introduce another three-way toggle for them.
In the “A” state all users are presented with the old version of the feature. Once we want to give the new one a try, simply switch the toggle into “A/B” mode. From that moment on, a sample of users will start seeing the new version.
After the product team gathers data on usage and picks what to do with the feature next, they can simply access the command center and either switch it to the “B” mode if it’s successful or do a rollback by switching back to the “A” state.
Having these ideas in mind, let’s take a brief look how industry leaders do it.
Some time ago, Facebook introduced a new feature called reactions.
It was controversial enough (overuse of anger reaction could make damage to Facebook’s positive feelings image that makes it friendly to advertisers).
Because of that, Facebook rolled it out gradually starting with Spanish and Irish markets. After a few weeks of tests and making sure that it was safe, they enabled reactions worldwide.
On the other hand some services, like Netflix, allow you to sign up for experimental features yourself.
This allows them to test new features on people that like to play with new stuff, without upsetting anyone else by letting them access partially finished features.
Spotify claims to test new features on a small group of users. Using feature toggles lets them easily run experiments and figure out if what they build is what users love.
As you see, the idea is quite popular amongst big companies. I could even risk saying that they couldn’t perform releases without having proper control over it.
But even if you’re not running software projects at Facebook, used by billions of users every day, it doesn’t mean you can’t get great benefits out of using it.
Borrowing Happiness from the Future
There’s last thing I need to mention. Even though feature toggles can help us relieve pain during the release, they’re still a mere painkiller, not a proper therapy.
Each feature toggle creates a new branch in code.
It’s easy to end up with a stack of feature toggles, each dependent on previously enabled ones.
What happens if someone switches off the toggle?
The off state probably worked at the time of its creation, but as new features come, some of them may accidentally rely on it being enabled.
These no longer used feature toggle states quickly become technical debt. They make it more difficult to maintain code and make the whole application more fragile.
In order to keep the development healthy, we need to remove unused code once the feature toggle is set into its final state.
As you saw, feature toggles are an extremely simple and extremely powerful tool for releasing new features. They give you a lot of flexibility when it comes to how and when to release, independently of any code changes.
They’re widely adopted by big internet companies, however they’re often overlooked by small companies that are busy building things that seem to be more important.
Speaking of that, they require minimum effort to implement.
You may want to give a try the next time you’re struggling with releasing a new feature.
Did you like this?
We write about building software products, no fluff included.
Leave your email and we'll let you know when we publish a new post.