Skip to Content
Author's profile photo Dirk Lehmann

Feature toggles or where to put in the complexity

I’m heading the technical operations of TwoGo by SAP, our cloud based ride sharing app, which got to be the first SAP cloud service which delivers software changes on a daily basis into its productive service.

In addition I’m doing a lot of evangelization inside and outside the company on DevOps culture and Continuous Delivery practices and one of the topics which again and again creates deeper interest is: feature toggles.

What is a feature toggle?

The operations point of view:

From an operations point of view, feature toggles separate the software deployment from the activation of the new feature or functionality.

In the on-premise world the deployment and the activation of a features is always one and the same event: you ship software to your customer which directly enables the customer to use the feature.

In the shiny new cloud world, feature toggles can separate this couple. We can deploy software on our productive system, while the new feature we’ve deployed is still not accessible by (every) user, as it’s hidden by some conditional.

Many successful cloud companies work in such a phased delivery model. Facebook actually calls this type of software releasing dark launching, as the user might already get some coding shipped on this client, which is just not visible/active (dark) to him/her.

The development point of view:

On a code level, a feature toggle is a simple conditional statement (if, case, ..) which checks whether a certain piece of code should be activated or not.

Here’s some feature toggle code from TwoGo:


what you can see is that for TwoGo the user object contains a list of features which must be activated for this user. In this case, the feature “Invite Friends” is checked and if the user does not have access to that particular feature, the code jumps out of this method as this particular function should not be made accessible to the user.

How to activate feature toggles?

In order to activate a feature toggle, we no longer need to deploy the related coding to our productive service, as the actual coding is already deployed (maybe since weeks), but it was just never activated. In order to activate the related piece of code, we need some administration view that allows us to activate features (in our case for a (group of) users).

This is how we activate features for TwoGo users:


We use an administration UI, which allows us to activate feature for certain users or user groups.

What are the benefits?

Using feature toggles allows us to do phased rollouts of our new functionality. We can activate new features only for certain users/groups (e.g. use our own team as gunee pigs) to test the new functionality. Does it work? Does it scale? Is it used at all?

In the worst case we might even deactivate the feature again, in case it does not work/scale/…

Any drawbacks?

Where there is light there is shadow. Feature toggles bring complexity into the code. The complexity which is now put into the code with feature toggles was -most likely- handled before (e.g. in on-premise) in source code versioning systems by tons of different branches/codelines (and a lot of double maintenance).

So complexity will not go away, it will just be somewhere else.

With feature toggles you need to enforce clean code, as you might end up in conditional statements everywhere in the code. So remove feature toggles from the code, when they are no longer needed.

(The same would you do with your old and no longer shipped/supported branches/codelines.)

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Shailaja Ainala
      Shailaja Ainala

      Very useful information Dirk