Feature Flags, Refactoring, and the Art of Technical Debt Management

Exhale! It's done.

That massive feature is finally deployed and in production.

You're feeling good, the stakeholders are happy to hear of the release, and surely the users are thrilled, too... right? Right?!

Not 5 minutes later, you get a Slack notification. It's from Carla, the sweetest customer support person ever.

Wait.

That was in #general?! Oh no.

You frantically pull `main` and test locally. Yep, it's busted.

Great. "Help."

You found the issue.

Hotfix branch. Commit. Push.

PR's up.

Right.

Tough pill to swallow, but it's possible that you're introducing other issues with frenetic fixes... and there's no guarantee that you're not resolving all issues.

Even though it stings, you revert.

Now we wait 20 minutes for things to build and deploy into production.

How many problems did YOU see?

What Are Feature Flags?

Feature flags, also known as feature toggles, are tools that enable development teams to separate feature delivery from feature release. Think of them as a magic switch. With a flick of this switch, you can turn a feature on or off without having to redeploy your code. Sounds fantastic, right?

But wait, there's more! Not only do feature flags allow you to control feature releases, but they also give your product team the power to make release decisions. This means, you, my dear developer friends, can focus on what you do best: creating and delivering awesome features, knowing that the when and who of the release is taken care of.

Benefits of Using Feature Flags

• Gradual Rollout: With feature flags, you no longer need to play the all-or-nothing game. You can release features incrementally, exposing them to a small subset of users before a full-scale rollout. This allows you to test the waters, gauge user reactions, and make adjustments before your feature makes its grand debut. It's like having the ability to walk before you run.

  
  

• A/B Testing: Imagine being able to present two different versions of a feature to your users, then sit back and watch which one they prefer. That's A/B testing in a nutshell, and feature flags make that possible.

  
  

• Canary Releases: Named after the proverbial canaries in coal mines, a canary release exposes a new feature to a small group of users before a full-scale rollout. This allows you to monitor the performance and potential impact of a feature in a controlled environment. If your feature performs well, you get to gradually scale up to full release.

  
  

• Operational Rollback: When things don't go quite so well and the canary stops chirping, we get to turn the code off without needing to deploy! Our systems become more resilient, our stakeholders don't "help" (as much), and our users' experience is affected as little as possible.

  
  

  
  

Feature flags are the safety nets that catch you when you fall. They're working behind the scenes to make your development process smoother, faster, and more efficient.

Now, let's look at these benefits side by side.

Implementing Feature Flags

Implementing feature flags isn't like rocket science...or even building Ikea furniture. Essentially, it involves wrapping your features (or parts of features) in conditional statements that check the status of the flag. There are a ton of feature flag management packages in many languages and some built into popular frameworks. There are flag management SaaS orgs that handle this for you. But, really, implementing these from scratch isn't much of a reach if you're into it.

Best Practices for Feature Flags

As the saying goes, "There's no such thing as a free lunch." (By the way, when I was doing some background work for this post, this saying is referred to as TANSTAAFL -- I'm struggling to believe this is real. Is this an acronym? Does it rhyme with "waffle" or is it a mouthful of an initialism? Seems dubious to me. I can get behind yagni, but tanstafle is a bit much.) When feature flags are no longer needed, the associated code with the unused logic branch AND the flag itself must be cleaned up and removed. If the clean up step is skipped, this is a sure way to end up with a tower of tech debt. The goal is a sleek, well-tuned codebase protected and enhanced by flags, not a bloated ball of mud.

Back to our example from the beginning. The most egregious problem IMO is letting the user be the conduit for release feedback. We need operational visibility. What problems did you see?