Feature Toggles and If-Conditions

In a span of three projects, where I had advocated for Feature-Toggles and CI, a common concern that I’ve heard from my colleagues regarding feature-toggles is this: why should we litter the code with those if-else blocks?

The only answer to that question is that we shouldn’t have to. And it’s a terrible idea if anyone thinks adding all those conditionals is alright.

I’m a proponent of CI, and I would rather that code is integrated often to the mainline as soon as possible so that everyone on the team sees it as soon as possible than it being hidden away in some branch. Feature Toggles are a tool that I frequently recommend for this.

But what about those if-conditions, again?

I believe this is a solvable problem, and it is a good problem to solve, because with a good code architecture and good abstractions, you will most probably not need to have those pesky if conditions littered everywhere. I’ve had to see these aforementioned if-else blocks for toggles (mostly) in very procedurally styled code-bases, with poor abstractions, and that is not a good place to be at anyway.

So how do I avoid if-else just popping up everywhere in the code?

The simplest trick in the book is to add a feature flag “on start-up” — implying my flags would be at a top layer of the code base, say at the DI framework level or maybe at the controller level where I might choose to add a Route or not depending on the state of the toggle. And that enables me to develop my feature in isolation below with no further if-conditions.

But then, if we are enhancing an existing feature, wouldn’t there also be if-conditions downstream? Yes, most probably.

But here is the catch: you may still don’t need to litter your codebase with those conditionals, if you had taken care to ensure that your classes were designed well, and with Single Responsibility Principle and Dependency Injection in mind from the get go. This is why they are so very important to watch out for.

And if you still need to build those if-conditions, maybe, you could put all of them together in an abstraction layer class (the branch by abstraction model) that you could remove by your IDE shortcuts when those feature toggles are no longer required. Reminds me a bit about the “I’ll just put this over here with the rest of the fire” line, but hey, it better than putting them all over the place.

Why all the fuss about Feature Toggles and Continuous Integration (CI), though?

CI is proven to improve team throughput and also, morale. And for a project that does CI, Feature Toggles are a very good tool in your toolbox. And like most cases in our line of work, maybe there is a price to pay to realise all this; but it’s also our part of our job to figure out how to reduce that cost.

In the case of toggles, sometimes figuring how to do that leads to better code architecture which is never a bad thing, and it is a task I would prefer any day, to resolving merge conflicts on bright and sunny morning.

This is something that my ex-TL told me

“Commits always go to production — Features are switched on and off as and when required”

That is when you and your team are truly continuously integrating. Good on you.