There is a huge variation in the lifetime of different feature toggles.
Looking at the number of days a feature toggle is live in the system, the histogram above shows that there is a huge variation. Fortunately, many teams are good at cleaning up, and a huge number of feature toggles are cleaned up within the first 50 days after creation. The histogram also shows that there is also a huge number of feature toggles that are forgotten and still exist in the system after 425 days.
Release toggles tend to have a life-time of a few weeks or less. In some cases they might live for more than a month, but in our experience this is more seldom. We also see that removing a release toggle is more often forgotten by teams. Based on our studies - most release toggles can be deprecated after 40 days.
The expected life-time of an experimental toggle is more unclear. The life-time does depend on the type of experiment and available amount of traffic. To get a statistically valid experiment, the dataset is of most importance. From our observations, these experiments tend to live for weeks and sometimes even months. We advise against experiments that are active for more than some weeks. If you don’t get a clear indication after a couple of weeks, you should reconsider the configuration of the experiment. For this reason, our recommendation is also that an experimental feature toggle should be deprecated within the first 40 days.
It is in the operational toggle category where we see the largest variance in the expected lifetime of the feature toggles. As with the Release category, they are usually introduced as part of a release of a new feature and they should be removed from the code as soon as the DevOps team gets confident that there are no issues. Still, quite often we do see that the DevOps team decides to keep some of the Operational toggles for a long period of time, sometimes even permanent. From our experience, this decision makes sense.
Feature toggles tech debt best practices
What are the suggested best practices working with feature toggles? Research done by North Carolina State University shows that a recommended best practice working with feature toggles is to use a feature toggle management system. The Feature toggle management system should provide a management UI that easily allows the team to get overview of the feature toggles in the system.
In order to handle feature toggle technical debt, the team is advised to early consider what release strategy that makes sense already part of the planning. This requires the team to consider the expected risk for issues that is expected when the new feature is released. Together with Product marketing management, the team should also understand if the release requires special attention from a product marketing point of view. These elements will provide an indication of the expected lifetime of the feature toggle.
The team should also consider the Definition-of-done (DoD). For the DevOps team, DoD usually is when the code is shipped to production. We argue that the DoD should include a step to remove the Feature toggle from the source code.
The teams should also start to apply functionality in the feature toggle system to stay on top of deprecated feature toggles. Unleash does provide a technical debt dashboard that displays the state of all toggles in your system.