Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Feature Flags: Theory vs. Reality

bpapillon.com

Post reply on HN
Print view View original

61–70 of 92 posts

Re: Feature Flags: Theory vs. Reality

#61

Post by travisjungroth »

mvdtnz wrote: post #29

These are real problems but not insurmountable. I think the author does an excellent job of laying out the problem and has pretty decent solutions in mind. I caution strongly against the proposed solution to fail CI if zombie flags are detected. CI should ONLY fail if there are changes in the branch that cause the failure. Detecting zombie flags (eg, this branch contains a flag which has been turned on and untouched…

The CI time bomb is the point. Other strategies are proven ineffective. It makes sense to either say:

1. The CI failures aren’t worth it. I accept the zombie flags.

2. Here’s a specific solution that will lead to zombie flags being removed and at a lower cost.

Gesturing to “find another way” doesn’t solve it.

Re: Feature Flags: Theory vs. Reality

#62

Post by q7xvh97o2pDhNrh »

6D794163636F756 wrote: post #35
marcosdumay wrote: post #21

Earlier quoted context omitted.

> getting a team to prioritise cleanup is difficult This is the limitation that breaks every development practice people come up with. That idea of formalizing the cleanup and requiring it for deployment is very interesting. It may be possible to extend it to other contexts.

It runs counter to the pressures a developer faces. I've at times been told that tech debt is fine because products only last 3-4 years before a replacement gets made. When you're on that timeline who cares if you've cleaned up after yourself?

> I've at times been told that tech debt is fine because products only last 3-4 years before a replacement gets made.

Translating from corp-speak, whoever said that probably meant: "I plan to get promoted before we need to pay this tech debt down."

Re: Feature Flags: Theory vs. Reality

#63

Post by chrsjxn »

DenisM wrote: post #58

Couple of simple ideas for the zombie flag problem: - When adding a flag immediately file a bug to remove the flag by a certain date. Enforce in code review. The bug count will surface the problem to the management. - When a flag is past due date start firing non-fatal incidents. The incident count will also surface the problem to the management.

Heh. I've been there and tried to do this with feature flags and a handful of other tech debt work.

It can feel good to make people do their chores, but you can also burn a _lot_ of bridges by forcing relatively minor maintenance work to be high priority like this.

Re: Feature Flags: Theory vs. Reality

#65

Post by DenisM »

chrsjxn wrote: post #63
DenisM wrote: post #58

Couple of simple ideas for the zombie flag problem: - When adding a flag immediately file a bug to remove the flag by a certain date. Enforce in code review. The bug count will surface the problem to the management. - When a flag is past due date start firing non-fatal incidents. The incident count will also surface the problem to the management.

Heh. I've been there and tried to do this with feature flags and a handful of other tech debt work. It can feel good to make people do their chores, but you can also burn a _lot_ of bridges by forcing relatively minor maintenance work to be high priority like this.

It’s not forced or high priority - it just surfaces tech debt to management in the way they can easily quantify and prioritize.

Re: Feature Flags: Theory vs. Reality

#66

Post by sjducb »

travisjungroth wrote: post #61
mvdtnz wrote: post #29

These are real problems but not insurmountable. I think the author does an excellent job of laying out the problem and has pretty decent solutions in mind. I caution strongly against the proposed solution to fail CI if zombie flags are detected. CI should ONLY fail if there are changes in the branch that cause the failure. Detecting zombie flags (eg, this branch contains a flag which has been turned on and untouched…

The CI time bomb is the point. Other strategies are proven ineffective. It makes sense to either say: 1. The CI failures aren’t worth it. I accept the zombie flags. 2. Here’s a specific solution that will lead to zombie flags being removed and at a lower cost. Gesturing to “find another way” doesn’t solve it.

The CI time bomb makes developers lives worse. You’re trying to get a new feature released, and some feature that everyone has forgotten about breaks the build and stops you from getting your feature out now.

If the stakeholders won’t allocate time in the roadmap to remove old feature flags then you shouldn’t use feature flags.

Re: Feature Flags: Theory vs. Reality

#67

Post by travisjungroth »

sjducb wrote: post #66
travisjungroth wrote: post #61

Earlier quoted context omitted.

The CI time bomb is the point. Other strategies are proven ineffective. It makes sense to either say: 1. The CI failures aren’t worth it. I accept the zombie flags. 2. Here’s a specific solution that will lead to zombie flags being removed and at a lower cost. Gesturing to “find another way” doesn’t solve it.

The CI time bomb makes developers lives worse. You’re trying to get a new feature released, and some feature that everyone has forgotten about breaks the build and stops you from getting your feature out now. If the stakeholders won’t allocate time in the roadmap to remove old feature flags then you shouldn’t use feature flags.

Good point. Don't do feature flags is the third option.

Re: Feature Flags: Theory vs. Reality

#68

Post by chrsjxn »

DenisM wrote: post #65
chrsjxn wrote: post #63

Earlier quoted context omitted.

Heh. I've been there and tried to do this with feature flags and a handful of other tech debt work. It can feel good to make people do their chores, but you can also burn a _lot_ of bridges by forcing relatively minor maintenance work to be high priority like this.

It’s not forced or high priority - it just surfaces tech debt to management in the way they can easily quantify and prioritize.

Maybe this is just a terminology mismatch, but when you say "incident" that's been a pretty urgent process everywhere I've worked. Other people are talking about breaking CI, which just sounds miserable.

Raising awareness to management is great though. Especially if you can quantify it in terms of things that matter to them more than "tech debt". Like startup latency or a direct dollar cost.

Re: Feature Flags: Theory vs. Reality

#69

Post by malfist »

phyrex wrote: post #59
malfist wrote: post #19

One thing I see missing in this article is another huge cost to these things. What happens when your homegrown feature flag microservice (because why pay for a hard cost when you can have the soft cost of making your own) goes down, even temporarily. Sane defaults at code review time, before launch aren't always the sane defaults after a feature has fully launched, or nearly fully launched. I've seen more than a few…

At my job feature flags (and other configuration) get distributed as static files that replaced by config updates, so if there’s ever a disruption the hosts still have the last valid code configuration values

That works for simple on off flags that can wait for a deploy to change. Adding rules on top of that become complex

Re: Feature Flags: Theory vs. Reality

#70

Post by VincentEvans »

marcosdumay wrote: post #21
zero_shift wrote: post #4

I'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…

> getting a team to prioritise cleanup is difficult This is the limitation that breaks every development practice people come up with. That idea of formalizing the cleanup and requiring it for deployment is very interesting. It may be possible to extend it to other contexts.

Shops could have people dedicated to such tasks rather than the usual feature work. Same as we now have devops teams, or even devex teams. For example I actually enjoy refactoring, cleaning up, and tending the garden. And I am sure I am not the only one - but the pressure is always to deliver features, so housekeeping is rarely done.
Post reply on HN