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 notification. It's from Carla, the sweetest customer support person ever. Slack 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? , 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? Feature flags 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 With feature flags, you no longer need to play the all-or-nothing game. You can release features , 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. Gradual Rollout: incrementally 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. A/B Testing: 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. Canary Releases: 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. Operational Rollback: 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. Benefit Description Gradual Rollout Allows for incremental release of features, reducing the risk of full-scale rollout failures A/B Testing Enables real-time user feedback on different feature versions to aid in decision making Canary Releases Facilitates performance monitoring of new features in a controlled environment before full-scale deployment Operational Rollback Provides the ability to scale back or disable features that have unintended consequences. 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." ( ) 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. 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. 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? Also published here.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Strategic Refactoring: A Roadmap for Tackling Technical Debt Head-On

Big O Notation: What Is It and Why Is It Important?

Join my newsletter

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

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

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

All The Different Flavors of Developer Entrepreneurship

10x Growth in 7 Months: How we Invest by Developing Software

10 Ways You Can Make Money Online From Your Home

10 Trendy Web Design Options to Make a Website That Converts

10 Tips to Develop a Strong B2B Relationship

All The Different Flavors of Developer Entrepreneurship

10x Growth in 7 Months: How we Invest by Developing Software

10 Ways You Can Make Money Online From Your Home

10 Trendy Web Design Options to Make a Website That Converts

10 Tips to Develop a Strong B2B Relationship

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps