Using Feature Flags? Don't Forget This Critical Step!

I remember the intensity in the COO’s eyes when he challenged my decision on a seemingly minor technical detail, "would you sign up for this feature flag service if this were your company?" he asked.

I sheepishly replied with an unconvincing response and we decided to gut the service shortly after.

To be honest, my team was right to not implement the service. It's not because feature flags are a bad idea, it's because I couldn’t properly communicate their value.

We were a small tech startup in a crowded market with major competitors. We had recently launched our beta product and needed to pump out new features fast. Feature flags were perfect for us but I didn't yet comprehend their power. When I first stumbled upon them, I had a hunch they could help us but it was such a new paradigm that it didn’t make complete sense to me.

For those of you that don’t know what a feature flag is, they provide a way to implement a new feature or change in your software product with the ability to hide or display it at will. For example, if your team has the idea to build a new video player, you can write the code for the new video player and launch it to your website while still showing the old video player to your users. Then, you can control which users see the new video player. Typically, you’ll ask those users to provide feedback or request changes before displaying the feature to the rest of your users.

When I first learned about this concept, it didn’t quite make sense. Why would we launch a new feature without releasing it to our entire customer base? It seemed like a slow and laborious process. If something went wrong or we needed to adjust something, why not just hot fix it?

Back then, I seemed to enjoy setting myself up to work frantically on nights and weekends.

Picture this: we'd just finished crafting a shiny new feature. We proudly showcased it to our team, then launched it on our app. We could almost hear the virtual high-fives echoing through the office. But just as we started to bask in the success, a call would come in. A voice from another department, bearing the unexpected 'gift' of last-minute, game-changing feedback that threatened to unravel our masterpiece.

The gift-giver of said feedback would often request that we revert the feature to hide it completely. This wasn’t always an easy task. We would fight tooth and nail about the changes and then scramble to find a way to implement them as quickly as possible.

Ah, those were the days…

The turning point came when we hired an engineer experienced with feature flags. He painted a clear picture: controlled releases, improved feedback, and less frantic hot fixes.

Shortly after we started using them, we instilled a policy where every new feature had to be behind a feature flag. It worked well. We started using feature flags in ways we hadn’t thought of. We were getting tons of feedback from the team without the stress of our customers seeing a half-baked feature.

But our success had a hidden pitfall. With every feature flag added, our code became a growing maze.

Our frontend code base was rapidly expanding because we were adding new code and not removing old code on the other side of each feature flag. This was increasing complexity which was slowing down development. Luckily I was the primary developer working on the frontend codebase and could manage it. However, on more than one occasion, I caught myself updating a component only to discover that it was a remnant of dead code we were no longer using. That’s when I realized the problem. We had a dozen of these feature flags that hadn’t been removed.

So, what’s the solution?

Clean up those dead feature flags!

I spent a half-day removing the legacy code to allow us to safely delete each feature flag.

Once a feature flag is turned on permanently, it is imperative that you take the time to remove the deprecated code and clean up the codebase to reflect the new feature in the switched-on state. This requires cross-team communication to let stakeholders and QA testers know that the code is being removed which will render the feature flag useless. Once the code is removed, you can safely delete the feature flag. Your code becomes pristine, your monthly bills shrink, and your engineering team radiates happiness.

Feature flags are an amazing new tool but they must be treated with caution. They’re powerful when used properly and dangerous when mishandled. The trick is to remove and clean up your code once you no longer need a feature flag.

So, the next time you're harnessing the power of feature flags, remember: it's not just about adding, but also about pruning. Keep your codebase lean and mean. Now, armed with this knowledge, go out there and build something truly amazing!