Feature Toggles — Faster Digitalization by Smart Experimentation

Faster digital transformation

Digital transformation never stops and never ends.

Your digital consumers expect new features for better a user experience, and more usability and comfort.

The ability to deliver features faster is great, but it comes with multiple risks. Many of them can be addressed by using feature toggles.

The idea is to create digital products with additional features, which include new and experimental ones, and allow them to be used only by particular users, in particular contexts and within specific time frames.

Another name for this strategy is “feature flags”.

In cases of success, the feature may be enabled for all the users and all the time, and in the case of bad reception or serious bugs it can quickly be disabled.

→ Dive deeper into Meeting the Future. Trends & Technology 2021.

Delivering new features

Even if the new feature or new modified versions of the feature seem to be a good idea, users may beg to differ. It is hard to predict their behavior, so the best way is to try and do it in an organized and safe way.

The Internet is filled with the posts of users who would like their old features back or don’t want a new feature at all.

Feature toggling enables the gradual rollout of features, gathering feedback, and then making informed decisions about modifying features, removing them or rolling them out to all the users.

It helps with A/B testing, canary releases (testing on a small subset of users), and even to try different performance optimizations in a production environment.

→ Explore How to dramatically improve your web app performance and security in one hour

User perception

Users usually feel better when they have access to additional features compared to other users. They feel special and they are more open to share their feedback, which includes excitement about the new feature, sometimes the one they’ve waited so long for.

→ Explore Sentiment analysis. Google Natural Language Processing vs Custom Algorithm

On the other hand, a very slow rollout of the feature is not the best for the users who are aware that there’s something they are missing compared to other users. In the current times, news about a new feature spreads fast and instead of excitement they experience frustration.

In my personal case as a user, it was always like that with dark mode for the applications. It took a long time to roll out the feature for the majority of users (sometimes months, I won’t mention the names here).

The remedy for this problem is to keep each feature toggle short lived. Their life span should not exceed weeks, otherwise they will become a source of frustration and of maintenance problems, which we will discuss later. They should stay or be removed based on the experiment’s results.

Feature toggles – known challenges

Feature toggles are good and useful from a business perspective, but nothing comes without its challenges. What is easy on the surface can become very difficult to deliver and maintain for the engineering teams.

Dependencies between features

Toggling features on and off seems very easy for business people.

But, all the software engineers know what is really creeping down underneath, the dependencies nightmare. Features may depend on each other, directly and indirectly because of their shared data or state. Preparing the code base to work with different features that are enabled or disabled is an effort and introduces more complexity than business users are willing and able to understand.

To make it even worse, features which seem to be independent from the business perspective are dependent from the technical and development perspective. There are known patterns to minimize this but there’s no silver bullet.

In a bad scenario, multiple features start to depend on each other at different times, as well as very heavily on code branches, that it is becoming very hard to disable one feature without affecting the other features and even the stability of the digital products altogether.

Disabling features leads to dead code

The code still exists even if the feature is disabled.

Every experienced software engineer knows how dangerous it may be to remove the code. Adding code requires a lot of attention, sometimes compared to stepping into a minefield of dependencies and unknown logic between components. In this metaphor, removing code is more like removing the active mine which means a risk of blowing up the entire solution.

Therefore many feature toggles are kept alive for too long, becoming a technological debt, and they will stay around … forever.

Multiple nodes with different versions

Modern microservice architectures mean multiple nodes with gradual rollouts of the new versions of the components.

In reality some of the nodes have the latest versions which support new feature toggles, while others still have previous versions which can not respond to a feature toggle.

So we may have three different situations: new components with the feature on, new components with the feature off and old components ignoring the feature.

It’s an often overlooked problem which needs to be addressed when implementing feature toggles. It’s perfectly doable but there’s additional complexity involved.

Testing complexity

Feature toggles mean more possibilities for different flows in the applications. From the testing perspective, each toggle may double the number of outcomes of the previous step in the workflow. It may significantly increase the number of test cases and data required to maintain the same level of testing coverage and quality.

It means additional effort and cost.

Architecture must be ready for feature toggles

Some think feature toggling is something that belongs to DevOps because it is closely related to the deployment and configuration of the digital products.

This is partially true, toggling features on and off, rolling back when it fails, etc. are undoubtedly DevOps things.

However, for the application to be ready for feature toggles, the entire application and components design has to be prepared, and it means another aspect of the architecture that has to be addressed. Toggles have to be triggered and have to be managed. There are already established architectural patterns such as decoupling decision points from logic, inversion of a decision, avoiding if-then-else, and strategy patterns for toggle implementation. First of all, we want to avoid creating permanent dependencies from business logic to the toggles.

Another important architectural decision is where to place the toggles. The most popular options are in the core of the business logic system and on the edge (API gateway, message routers). The decision depends on the particular feature and how deep it is related to the logic of the application.

→ Explore sour take on Evolutionary architectures in practice

What’s next for feature toggles?

There are good toggles and bad toggles, and there are toggles made well and made bad. The idea of trying new features and delivering better digital experiences faster is so tempting that the question is not “if” but “how”.

And that’s where our architecture, development and DevOps teams from Avenga can help.