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

Uber open-sources tool to automatically clean up stale code

infoq.com

Post reply on HN
Print view View original

21–30 of 70 posts

Re: Uber open-sources tool to automatically clean up stale code

#21

Post by wahlrus »

erik_seaberg wrote: post #19
solidasparagus wrote: post #18

Earlier quoted context omitted.

How do you test without a feature flag?

The flag becomes a percentage. The feature isn't always off or always on, it's on for a small fraction of workload, and then that fraction grows as you demonstrate it's safe. Ideally you want metrics that tell you whether the experiment is worse or better than the control group.

What you're describing is a common way of using feature flags—except the percentage part comes from how you manage the servers running the binary with config. I.e. on day one, 5% of servers in cluster get True for the flag value. The double the percentage every day until 100% or otherwise rollback if it's a bad cut.

Re: Uber open-sources tool to automatically clean up stale code

#22

Post by cdcarter »

erik_seaberg wrote: post #17

I'm surprised to see that Boolean feature flags are common. We almost always ramp up percentages of UUID space or randomly chosen requests, to reduce the blast radius of a bad change.

At $JOB, we have feature flags of innumerable shapes and sizes. Some are based on account standing, some are % gradual rollout at random, others are a more thoughtful low-risk to high-risk rollout across customers and hosts. Some are manual flipped per customer/only on certain dev hosts. Literally anything you can think of, we have tied behavior to it.

But, we've got good frameworks in place such that at the call sites where behavior diverges, it's just checking a boolean.

if PermissionController.get().get(MyPerm.class): doA() else: doB().

I suspect this is pretty common, and its still easy to do the dead code elimination on.

Re: Uber open-sources tool to automatically clean up stale code

#23

Post by novok »

erik_seaberg wrote: post #17

I'm surprised to see that Boolean feature flags are common. We almost always ramp up percentages of UUID space or randomly chosen requests, to reduce the blast radius of a bad change.

Many feature flag systems ramp up doing that from the config server side. So when your client requests feature flags, it gets assigned true/false on that basis.

Re: Uber open-sources tool to automatically clean up stale code

#25

Post by Thaxll »

erik_seaberg wrote: post #19
solidasparagus wrote: post #18

Earlier quoted context omitted.

How do you test without a feature flag?

The flag becomes a percentage. The feature isn't always off or always on, it's on for a small fraction of workload, and then that fraction grows as you demonstrate it's safe. Ideally you want metrics that tell you whether the experiment is worse or better than the control group.

This is not feature flag then it's A/B testing.

Re: Uber open-sources tool to automatically clean up stale code

#26

Post by solidasparagus »

erik_seaberg wrote: post #19
solidasparagus wrote: post #18

Earlier quoted context omitted.

How do you test without a feature flag?

The flag becomes a percentage. The feature isn't always off or always on, it's on for a small fraction of workload, and then that fraction grows as you demonstrate it's safe. Ideally you want metrics that tell you whether the experiment is worse or better than the control group.

But how do you test the feature without a boolean flag that you can set to enable the feature?

Re: Uber open-sources tool to automatically clean up stale code

#27

Post by foota »

solidasparagus wrote: post #26
erik_seaberg wrote: post #19

Earlier quoted context omitted.

The flag becomes a percentage. The feature isn't always off or always on, it's on for a small fraction of workload, and then that fraction grows as you demonstrate it's safe. Ideally you want metrics that tell you whether the experiment is worse or better than the control group.

But how do you test the feature without a boolean flag that you can set to enable the feature?

You mean unit testing? You can add a way in your framework to force the flag on.

Re: Uber open-sources tool to automatically clean up stale code

#28

Post by hoorayimhelping »

solidasparagus wrote: post #26
erik_seaberg wrote: post #19

Earlier quoted context omitted.

The flag becomes a percentage. The feature isn't always off or always on, it's on for a small fraction of workload, and then that fraction grows as you demonstrate it's safe. Ideally you want metrics that tell you whether the experiment is worse or better than the control group.

But how do you test the feature without a boolean flag that you can set to enable the feature?

I think it might be less confusing to say, how do you verify the feature? As in: how do engineers and product managers and designers know that the flagged behavior is correct and how do you verify that in production if all you do is ramp up? How do you make sure the interested parties are always bucketed into the on experiment?

Re: Uber open-sources tool to automatically clean up stale code

#29

Post by stuckinaloop »

burtonator wrote: post #24

We just wrote one that does something similar for Typescript if anyone wants us to OSS it... The idea is that any stale code causes a HUGE amount of headache and removing it can be a life safer.

I you were to OSS it I would definitely use it!

Re: Uber open-sources tool to automatically clean up stale code

#30

Post by fennecfoxen »

cdcarter wrote: post #22
erik_seaberg wrote: post #17

I'm surprised to see that Boolean feature flags are common. We almost always ramp up percentages of UUID space or randomly chosen requests, to reduce the blast radius of a bad change.

At $JOB, we have feature flags of innumerable shapes and sizes. Some are based on account standing, some are % gradual rollout at random, others are a more thoughtful low-risk to high-risk rollout across customers and hosts. Some are manual flipped per customer/only on certain dev hosts. Literally anything you can think of, we have tied behavior to it. But, we've got good frameworks in place such that at the call sit…

> if PermissionController.get().get(MyPerm.class): doA() else: doB().

oh, but if a behavior changes when a feature flag is active, there's a very strong case for it to be pluggable behavior strategy, so I like these so much better as an unconditional call to `self.getThingStrategy().execute()`

Post reply on HN