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

11–20 of 70 posts

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

#11

Post by snthd »

joering2 wrote: post #3

Total nit pick, but I think Piranha is a totally wrong name here. Piranhas mostly feed on fresh meat, its known they are excited and eager to attack when victim moves in water, reassuring predator that its a healthy meat. Much better name would be Scavenger, or Vulture - a bird of prey that eats on dead meat. I assume you would rather cleanup your program from dead code, rather than strip it down to the bone from liv…

https://en.wikipedia.org/wiki/Maggot_therapy might be a better analogy - you don't want to lose everything, just to clean out the necrotic bits.

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

#12

Post by Swizec »

laydn wrote: post #10

I find it strange that a company which provides taxi hailing/routing technology felt the need to write a code cleanup tool.

When a company really loves growth and her VC daddy measures growth in headcount and all those talented engineers need something to do ...

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

#13

Post by malux85 »

laydn wrote: post #10

I find it strange that a company which provides taxi hailing/routing technology felt the need to write a code cleanup tool.

A company with billions in revenue, live updates routing around traffic, has complex machine learning modes predicting ride times and costs, and operates in something like 65 countries.

Uber isn’t trivial

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

#14

Post by read_if_gay_ »

laydn wrote: post #10

I find it strange that a company which provides taxi hailing/routing technology felt the need to write a code cleanup tool.

You can make most of the Big N sound silly like this. Amazon? Basically a warehouse. Netflix, YouTube? They just stream video. Facebook, Twitter? CRUD websites.

It all sounds like anyone can put something like that together, but try scaling up to billions of users.

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

#15

Post by argonix »

laydn wrote: post #10

I find it strange that a company which provides taxi hailing/routing technology felt the need to write a code cleanup tool.

Uber's article [1] linked on the page mentions it at the start:

> These nonfunctional feature flags represent technical debt, making it difficult for developers to work on the codebase, and can bloat our apps, requiring unnecessary operations that impact performance for the end user and potentially impact overall app reliability.

> Removing this debt can be time-intensive for our engineers, preventing them from working on newer features.

[1] https://eng.uber.com/piranha/

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

#16

Post by speedgoose »

read_if_gay_ wrote: post #14
laydn wrote: post #10

I find it strange that a company which provides taxi hailing/routing technology felt the need to write a code cleanup tool.

You can make most of the Big N sound silly like this. Amazon? Basically a warehouse. Netflix, YouTube? They just stream video. Facebook, Twitter? CRUD websites. It all sounds like anyone can put something like that together, but try scaling up to billions of users.

For sure if you remove the scalability challenges and profits optimizations techniques, these websites aren't that exciting for engineers.

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

#18

Post by solidasparagus »

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.

How do you test without a feature flag?

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

#19

Post by erik_seaberg »

solidasparagus wrote: post #18
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.

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