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

71–80 of 92 posts

Re: Feature Flags: Theory vs. Reality

#71

Post by tomhallett »

deathanatos wrote: post #54
no_wizard wrote: post #41

Earlier quoted context omitted.

This is the only way, more or less, to enforce any code standards, whether its refactoring, quality, testing, docs etc. If it doesn't break the build (or do anything else that stops it from moving forward) there will always be external pressure to get things out "ASAP" despite in most circumstances "ASAP" isn't required. If you can't full on stop whats happening, it becomes exponentially harder to enforce anything.

I agree with you, entirely, but I've had developers fight tooth and nail when the build breaks. "We need to get out there ASAP!" is definitely the cry, and usually "compromises" are made, such as "what if we made the overall CI run not fail if this test fails?" — which is as good as killing the test, IMO. The impetus is necessary, or the problem is ignored. The devs are really just proxies for the stress a PM is inap…

Agreed, but at least with the override mechanism being as visible as the test suite, you have assured that more people will know about it (bringing it "to the surface") and you might even have the override in source control (documented). These aspects are increasing the chances someone will say "Let's just follow the process."

Re: Feature Flags: Theory vs. Reality

#72

Post by hakfoo »

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…

Our feature flags tend to be "staged deploy" feature flags, and it hits an internal Slack channel when they hit 100% available. This usually triggers someone to queue up a ticket for "rip out the old code".

Re: Feature Flags: Theory vs. Reality

#73

Post by scrubs »

I worked at bloomberg for an extended period. Feature flags are seriously used eg. >10k flags added per month across all code. Now, they came with ample management systems to enable/disable, rollout, and check for complete rollout. Various techniques (shared memory, caching) were used to drive down lookup time.

Removing them came down to team discipline.

Ideally, a Google like clang analysis of code would find flags ready for removal and alter code to remove the old code path. Recall Google used tools like this ro update or migrate deprecated api calls

Bbg however never got there. Instead you'd just get various alerts

Re: Feature Flags: Theory vs. Reality

#74

Post by slaymaker1907 »

daliwali wrote: post #46

At my work, I have a somewhat clever (or idiotic) technical solution to the problems of feature flags: they are actually implemented as feature modules that monkey-patch the base application in runtime. There are a few benefits: removing features is dead simple, just delete the whole feature module, and there's no conditional branching in the base application. There are some drawbacks too: the base application must h…

That sounds kind of complicated to reason about and thus pretty dangerous for feature flags. At my work, we use them to do partial rollbacks in case the new feature/behavior has unintended consequences. Deployments might take weeks to complete globally, so doing a hotpatch or code rollback is incredibly expensive compared to toggling a feature.

Re: Feature Flags: Theory vs. Reality

#75

Post by [deleted] »

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…

[deleted]

Re: Feature Flags: Theory vs. Reality

#76

Post by noelwelsh »

If you want a repeatable task done properly every time you give it to a computer. In this case, manipulating feature flags is a task for partial evaluation / staging. It's relatively well known in the programming language research community but hasn't made it into mainstream production languages. No amount of social process will ever be as effective.

Re: Feature Flags: Theory vs. Reality

#77

Post by rewmie »

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.

Here am I, sipping on my coffee and catching up on HN while waiting for my 10+ year project to finish building.

Building what? A feature flag, of all things.

Re: Feature Flags: Theory vs. Reality

#78

Post by qohen »

morgante wrote: post #34

It seems like one of the biggest problems is prioritizing the cleanup of old flags. I know some companies have developed tools like Piranha[0] to automate this process and a few of our customers at grit.io have used it for that as well. Would love to hear if others have had success with automated flag cleanup.

[0] https://www.uber.com/blog/piranha/ (https://github.com/uber/piranha)

;-)

Re: Feature Flags: Theory vs. Reality

#79

Post by arein3 »

alexjurkiewicz wrote: post #60
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…

What prevents teams extending the expiry date repeatedly?

The lead and other membera of the team that understand that temporary fixes should not be forever.

Re: Feature Flags: Theory vs. Reality

#80

Post by phyrex »

malfist wrote: post #69
phyrex wrote: post #59

Earlier quoted context omitted.

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

No, the deploy mechanism is separate from a code deploy. The rules themselves can get very complex and are distributed in the same way
Post reply on HN