Live data from Hacker News

Piranha: An Open Source Tool to Automatically Delete Stale Code

eng.uber.com

1–10 of 50 posts

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

#5

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 removed, b) actually removing the code and putting the diff up. Piranha diffs for a single flag are also generally small enough to fully read them during code review.

We do have comprehensive unit tests for both the Piranha tool and the target codebase(s), and the majority (65%) of diffs generated by Piranha are landed without changes (and the most common change in those that are changed is to delete extra lines that Piranha couldn't prove as stale). Thus far we haven't had an outage caused by a Piranha deletion, but certainly there have been incorrect diffs generated and caught either by CI or manual reviewers, requiring us to update the tool. We would not recommend landing diffs generated by Piranha - or other stale code removal tools - to master without any reviews right now :)

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

#8
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.

Brilliant. This reminds me of the apocryphal tale where NASA spent millions developing a pen that could work in microgravity… and Russia just used a pencil.

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

#9
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
Post reply on HN