How to Manage Outdated Feature Flags

Not cleaning up feature flags can introduce risk to your code base. Learn how Feature Flag Removal Day can lead to better feature management.

Feature flags (aka feature toggles) are a gold standard of agile software development and continuous integration for good reason: they help teams deliver new features to customers safely, and with better control. If you’ve ever needed to validate new functionality with end users (hint: test code in production!), quickly roll back a change, or run an A/B test on a feature, you might be a fan of feature flags too. They help de-risk feature releases and code deployment.

But as a DevOps engineer, feature flag management can also give you heartburn. When they’re mismanaged, you can end up with a codebase littered with old, forgotten feature flags that actually introduce risk.

A Feature Flag Removal Day is a simple, effective way to manage feature flags responsibly.

A feature flag whose job is complete should be removed 

Feature flagging lets you roll out code rapidly and safely. But once your experiment is complete or the rollout has been fully deployed with no chance of rollback, an engineer should remove it as a feature flag best practice. 

Not doing so opens up the possibility of exposing your customers to the wrong feature or to code base breaking functionality.

That said, it can be hard to prioritize managing feature flags and ownership isn’t always clear. You can set expiration dates for your feature flags, but developers can become swamped with other projects, leave the team, or just need repeated, gentle prodding to prioritize removal. Feature Flag Removal Day can help you cut through all that.

Why a Feature Flag Removal Day?

Feature Flag Removal Day is one day each month when developers swarm to remove feature flags that have completed their job. The session generally lasts 4-6 hours — we order donuts to keep the energy high! At Optimizely, some squads come together to remove flags as a group; others assign a single developer to own the task. 

The goal isn’t necessarily to have all flags removed during the session. We use the time to audit expired feature flags, check that the exit criteria has been met, and assign owners.

Designating a specific day gives developers a set time to swarm together to help approve the Pull Request changes for removing their feature flags.

It also has the following benefits:

• A human check: You can build in a human check with the Product Owner to make sure that each flag on the list should be removed. 
• Socializes feature flag hygiene practices: Leaving too many flags in your code base can cause technical debt and make the code base brittle. A well-publicized day can help you make your whole organization aware of this risk. Tackling it regularly should become part of the culture of your development teams.
• Lightweight, reliable process: Remove the back-and-forth debates about each flag that should be removed by establishing a standard practice and set cycle. At Optimizely, this helps us avoid the anxiety that feature flags of past employees might come back to haunt us. 
• Clear, time-bound ownership: Instead of making your developers own a specific feature flag forever, let the process handle it. On Feature Flag Removal Day, assign a developer the responsibility for removing that flag — case closed.
• Transparency: Give your entire engineering organization notice that certain feature toggles are being removed. This reduces the chance that a flag that’s in use by one team might be removed by another.
• Efficient use of developers’ time: Chunk out a specific time for your developers to work on removing their feature flags. Then, they can go back to their regularly scheduled programming.

Which flags should be removed?

The goal is to remove all feature flags that are no longer actively in use as part of an experiment or rollout.

On our first Feature Flag Removal Day at Optimizely, we evaluated every single flag that fit the following criteria:

• Flags that were created before 2019
• Flags that haven’t been updated since 2019 
• Flags that don’t have a specific target audience attached, meaning they’re exposed to everyone
• Flags that are rolled out to 100% of the user base and 100% in the production environment
  

We identified 11 flags that matched this criteria.

We spoke to the Product Owners for each feature to ensure that they could be removed. We found two that shouldn’t be removed (one was a kill switch, the other maintained a legacy feature for certain customers). We updated these flags with an exit criteria and their expiration date blank. 

We investigated the remaining nine. 

What we found

Some of the code had already been removed, but the flags were still listed in our feature flagging system dashboard. We archived these and called it a day.

A few feature flags were more difficult to remove because they were distributed throughout the code base and required multiple developers from different product teams to remove. These took longer than a day and multiple code reviews to remove.

But the majority of flags were easily and cleanly removed.

Bonus: The practice of removing flags gave developers a different perspective on best practices for implementing them. Placing them higher in the code base and taking them out earlier makes them easier to rip out later.

Future plans for feature flags

Our feature flag best practices now include an exit criteria and an expiration date. These markers help us manage how and when we remove our flags. 

The exit criteria is a condition that qualifies the feature flag to be removed. For example, if a flag has been rolled out to the public at 100% and no major bugs have been reported, it can be removed in 30 days (the expiration date).

We set this exit criteria when we write feature acceptance criteria, as an agreement between:

• Developer: The engineer who implements the feature flag.
• Product owner: the project manager who decides the feature rollout strategy, writes the initial removal criteria, and communicates the feature to customers.
• QA team: Auditors who ensure that the policy was executed correctly.

Our removal process looks like this:

1. QA team checks the Features dashboard in Optimizely to identify all flags that have met their exit criteria.
2. Flags whose expiration date falls before the next Feature Flag Removal Day are listed in a new Jira epic. 
3. QA tags the developer who implemented the flag and invites them to the next Feature Flag Removal Day event. 
4. On Feature Flag Removal Day, developers gather to swarm on removing their feature flags and archiving them in the Optimizely Features dashboard. 

In Conclusion

Setting a dedicated day once a month helps build a practice of reviewing every feature flag in the code base at regular intervals to ensure that only the right flags are live. This has given our Engineering team better visibility into the number of flags in flight, and helps us measure work in progress (WIP) as part of our agile product management and development process. By actively auditing our feature flags on Feature Flag Removal Day, we ensure that Optimizely can safely and rapidly release product, while keeping the code base safe and clean. 

If you want to get started with feature management, you can check out Optimizely Rollouts for unlimited feature flags and controlled rollouts.