I've written about early integration and why it leads to better features. While this is true you might not want to roll out changes to all users at once. For instance, you might be working on a feature for a very specific target group and want to make sure that once you release it for everyone there are no major hick-ups. At the same time, you don't want the source code to diverge and rot on a long-lived branch. Enter stage: feature toggles.
Feature toggles allow us to reintegrate new features early but only activate them for certain customers at a time. This can be used for beta testing, A/B testing, and more.
That's great until some of our POs required every new feature to be behind a toggle. This might sound like a reasonable idea but let me explain why I think you should try to keep the number of feature toggles to a minimum.
Feature toggles are if-statements on steroids1.
For instance, if you have one (also known as McCabe complexity)?
In a nutshell, this metric tells you how many distinct paths there are in your code
if-statement then there are two possible paths.
false (i.e. the
I think the most basic lecture I give to less experienced engineers is how to reduce the amount of
if-statements in code.
Because the more conditionals there are the harder it is to reason about the code.
Now, if you're on the lookout for this kind of complexity on a method level, then you should definitely be on the lookout on the feature level. Each feature you're toggling adds a condition to your application. One path where the feature is active and another one where it isn't.
What this means is that you'll need to add integration tests for all possible scenarios where different features overlap. This can add significant effort to your development process. It can also increase the chance of defects that are harder to trace because your production system might have many different feature configurations.
When everything is toggled nothing is doneWIP limit on non-GA features. Oof. If that's the case then we might have removed bottlenecks from our development process but we've added a monster of a bottleneck at the end. This is problematic because we're doing a lot of work and not all users can see it. If not all users can use it you're going to miss edge cases. When you're missing edge cases you create defects.in most development boards I've seen teams use. That means that there is no
Long story short: a feature that is toggled cannot be considered done. When a feature is not done this should prevent the team from starting something else. If this isn't the case you have a problem.