Feature Flags: Theory vs. Reality
bpapillon.com
Feature Flags: Theory vs. Reality
1–10 of 92 posts
Re: Feature Flags: Theory vs. Reality
#2We're attempting to address some of these problems at https://www.flipt.io/gitops. Having your flags defined as configuration and committed to repository opens up a range of possibilities in terms of static analysis.
Additionaly, we've got a prototype static analysis tool to finding calls to our feature flag clients in both Go and Rust too.
Re: Feature Flags: Theory vs. Reality
#3Modern feature flag tooling (eg. LaunchDarkly) cover most of the uses here. It'll even tell you whether flags are useful or not (if you push evaluation data back upstream).
Re: Feature Flags: Theory vs. Reality
#4I've definitely lived with the zombie flags problem. Teams ship experiments that double the size of a piece of code, but never go back to refactor out the unused code branches. In shared codebases this becomes a nightmare of thousands of lines of zombie code and unit tests.
This is a social problem as much as a technical one: even if you have LaunchDarkly, DataDog etc making very clear that a flag isn't used, getting a team to prioritise cleanup is difficult. Especially if their PM leaned on engineers to make the experiment "quick n dirty" and therefore hard to clean up.
At The Guardian we had a pretty direct way to fix this: experiments were associated with expiry dates, and if your team's experiments expired the build system simply wouldn't process your jobs without outside intervention. Seems harsh, but I've found with many orgs the only way to fix negative externalities in a shared codebase is a tool that says "you broke your promises, now we break your builds".
Re: Feature Flags: Theory vs. Reality
#5Modern feature flag tooling (eg. LaunchDarkly) cover most of the uses here. It'll even tell you whether flags are useful or not (if you push evaluation data back upstream).
Good point. It's possible the real issues have more to do with price point/positioning and product UX.
My experience with LaunchDarkly has been that a lot of these hygiene-related exist only in their top tier enterprise plans, and even below that point the cost of the tool starts to draw attention.
On the product UX side - I've found these tools are designed for engineering/Devops users but (whether by design or not) by product, success, and some ops users as well.
Re: Feature Flags: Theory vs. Reality
#6We're attempting to address some of these problems at https://www.flipt.io/gitops . Having your flags defined as configuration and committed to repository opens up a range of possibilities in terms of static analysis. Additionaly, we've got a prototype static analysis tool to finding calls to our feature flag clients in both Go and Rust too.
Hadn't seen this, looks very cool! The static analysis piece seems difficult, but even considering that I've been a little surprised not to see more attempts.
Re: Feature Flags: Theory vs. Reality
#7Yep, everything in this article is right on my money in my experience.
Re: Feature Flags: Theory vs. Reality
#8Are there any authorization products that handle feature flagging as an application?
Re: Feature Flags: Theory vs. Reality
#9I've definitely lived with the zombie flags problem. Teams ship experiments that double the size of a piece of code, but never go back to refactor out the unused code branches. In shared codebases this becomes a nightmare of thousands of lines of zombie code and unit tests. This is a social problem as much as a technical one: even if you have LaunchDarkly, DataDog etc making very clear that a flag isn't used, getting…
A softer solution is to name and shame with periodic "leaderboard" emails to the org showing how many experiments each team has failed to clean.
Re: Feature Flags: Theory vs. Reality
#10I've definitely lived with the zombie flags problem. Teams ship experiments that double the size of a piece of code, but never go back to refactor out the unused code branches. In shared codebases this becomes a nightmare of thousands of lines of zombie code and unit tests. This is a social problem as much as a technical one: even if you have LaunchDarkly, DataDog etc making very clear that a flag isn't used, getting…
Totally agree that it is a social problem as much as a technical problem. This is one reason why I had the thought here of FM tools starting to own some "feature management" jobs that aren't typically placed under the devops umbrella, and may be more of interest to product or marketing stakeholders. Perhaps that would do something to help with the issue of getting buy-in to do the maintenance.