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

Piranha: An Open Source Tool to Automatically Delete Stale Code

eng.uber.com

Post reply on HN
Print view View original

21–30 of 50 posts

Re: Piranha: An Open Source Tool to Automatically Delete Stale Code

#21

Post by rkangel »

ThouYS wrote: post #19
ublaze wrote: post #4

One of our internal experimentation systems handles this by capping rollouts to 95%. So the author is forced to clean up their code if they want a full rollout.

I'm sorry, but I don't entirely get this. Does it mean that after I've finished something I want to merge, I have to remove 5% of that? Or of the entire code base? Or something completely different?

I think they're saying that any new feature controlled by a flag is only rolled out to a maximum of 95% of the user base. To make sure it gets rolled out to 100% you have to remove the flag controlling it (and therefore the old version of the code).

Re: Piranha: An Open Source Tool to Automatically Delete Stale Code

#22

Post by another-dave »

bluesign wrote: post #18

If I am not mistaken this tool requires technical debt to begin with. I think more important part is what caused this debt to begin with. In my opinion it lies in the implementation of feature flags.

Can you expand a bit on what you mean here?

How would you introduce feature flags in a way that doesn't leave any debt behind in contrast to their approach?

Or are you saying that feature flags themselves are inheritly debt-generating (which I think they acknowledge, but are taking it on prudently & deliberately) — in which case, what would you do instead?

Re: Piranha: An Open Source Tool to Automatically Delete Stale Code

#23

Post by capableweb »

obilgic wrote: post #9
ublaze wrote: post #4

One of our internal experimentation systems handles this by capping rollouts to 95%. So the author is forced to clean up their code if they want a full rollout.

this eliminates the ability to do a revert though if things don't work as expected at %100

I'm not doubting it's impossible, but I can't come up with any scenarios where something would work perfectly at 95% but then break at 100%. What could be some examples of things that can break like that?

Re: Piranha: An Open Source Tool to Automatically Delete Stale Code

#24

Post by bluesign »

another-dave wrote: post #22
bluesign wrote: post #18

If I am not mistaken this tool requires technical debt to begin with. I think more important part is what caused this debt to begin with. In my opinion it lies in the implementation of feature flags.

Can you expand a bit on what you mean here? How would you introduce feature flags in a way that doesn't leave any debt behind in contrast to their approach? Or are you saying that feature flags themselves are inheritly debt-generating (which I think they acknowledge, but are taking it on prudently & deliberately) — in which case, what would you do instead?

Actually what I meant was this tool is kind of a after thought of bad feature flag life cycle. When you set a feature flag, normally you should put a deadline on it, after this deadline, you should either choose to keep it, or remove it or you can extend the deadline.

But seems like they accumulated a lot of flags, which stayed stale over time, and went unchecked and lack of feedback created the debt.

Also unrelated but I prefer 2 stages for retirement of flags, from production and from code. From the example in the article. Instead of using direct access to:

experiments.isTreated(RIDES_NEW_FEATURE)

I think it is better to indirectly refer this from a function like (considering we are in context of RIDES module/class):

function isNewFeatureEnabled(){ return experiments.isTreated(RIDES_NEW_FEATURE) }

So when you want to retire this flag to disable new feature but want to keep code for some time (for few versions), but don't want to bloat your binary you can simply do:

function isNewFeatureEnabled(){ return FALSE }

Re: Piranha: An Open Source Tool to Automatically Delete Stale Code

#25

Post by bluesign »

ublaze wrote: post #4

One of our internal experimentation systems handles this by capping rollouts to 95%. So the author is forced to clean up their code if they want a full rollout.

This is solving half of the problem though, failing experiments still clutter the code.

Re: Piranha: An Open Source Tool to Automatically Delete Stale Code

#26

Post by Shish2k »

capableweb wrote: post #23
obilgic wrote: post #9

Earlier quoted context omitted.

this eliminates the ability to do a revert though if things don't work as expected at %100

I'm not doubting it's impossible, but I can't come up with any scenarios where something would work perfectly at 95% but then break at 100%. What could be some examples of things that can break like that?

I saw something like that one time - the new version had one rarely-used broken API endpoint; clients who hit that would silently retry until eventually hitting an old instance which worked and then they’d be on their way. It was rarely used enough that the total number of retries didn’t trigger any alarms, and failed fast so that failing 19 times before working on the 20th attempt didn’t cause any timeouts.

We now have monitoring of success-rate-per-endpoint, so even if 99.9% of requests are successful, if a single function crashes 100% of the time we should still notice :)

Re: Piranha: An Open Source Tool to Automatically Delete Stale Code

#28

Post by dean177 »

smabie wrote: post #16
dean177 wrote: post #13

Earlier quoted context omitted.

Please stop repeating this, it’s total nonsense.

That's why he said apocryphal..

Which means they are of doubtful origin. There is no doubt that this particular story is a complete fabrication

Re: Piranha: An Open Source Tool to Automatically Delete Stale Code

#29

Post by awinter-py »

this seems to work by comparing feature flag configs

I've always been a buyer of tools to make runtime stats available in the IDE

would be awesome to overlay trace / route timing into the codebase on whatever part of the call graph is on the screen

Re: Piranha: An Open Source Tool to Automatically Delete Stale Code

#30

Post by victords »

lazaroclapp wrote: post #5
RickJWagner wrote: post #3

It sounds pretty fancy. I'd want a very thorough set of unit tests before trusting code to delete code, though.

Piranha co-author here. I'd say you trust it a bit more than we do, then ;) As the paper and blog post mention, we use Piranha to create diffs/PRs against the original author of the code. Developers are expected to code-review the changes before they are ever landed. As used within Uber, Piranha won't ever auto-land code deletions. That still saves the time of: a) remembering that the flag is stale and must be remove…

Follow up question: In general, when a diff is generated, is the standard process to just do a manual code-review and CI, or do you also test it manually to check for unexpected side-effects?
Post reply on HN