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

A former Uber engineer's disaster story

twitter.com

Post reply on HN
Print view View original

121–130 of 344 posts

Re: A former Uber engineer's disaster story

#121

Post by lisardo »

nwsm wrote: post #14

Great thread. > So said brilliant engineer in Amsterdam, built an annealing algorithm in the release build to reorder the optimization passes in such a way to as minimize size. This shaved a whooping 11 mbs off the total machine code size and bought us enough runway to keep development going. > This terrified the Swift compiler engineers, they were worried that untested complier pass orders would expose untested bugs…

> annealing algorithm in the release build to reorder

This is a damn cool use of simulated annealing.

Re: A former Uber engineer's disaster story

#122

Post by pandanomic »

lern_too_spel wrote: post #44
nobunaga wrote: post #23

Earlier quoted context omitted.

Android was a much easier story, Still had some binary size and method count issues but we were able to overcome them thanks to another brilliant engineer we had in the team in SF who worked on Android.

The Android apk is 56.9 MB for my device, while the iOS app is 331.3 MB. What accounts for the 6x difference?

Swift produces far larger binaries

Re: A former Uber engineer's disaster story

#123

Post by saagarjha »

nwsm wrote: post #28
nobunaga wrote: post #21

I was part of the team in Amsterdam on this. Insane days. Had some great engineers we hired in AMS. We were moving the whole source code into a monorepo as well which was another crazy project. I think if we had not had some of the engineers we did at those exact times, we would have not gotten out of it. Problem here with Swift came down to - Apple not dogfooding its own tech . Hell they did not even help us or othe…

Appreciate your insight, and I'm sorry to hear about the AMS team. The OP indicates that a rewrite was necessary regardless. Even if Swift was not yet mature, do you think it was more worthwhile than rewriting in ObjC? Given that the goal was to "sustain mobile development at Uber for the next 5 years". Secondly, I'm not a mobile developer so I don't have much context, and I'm wondering about your outlook on iOS deve…

The Mac CI situation has gotten much worse this year, but Swift has gotten much better. Writing a large app in Swift is still a major undertaking, but there are people doing it these days.

Re: A former Uber engineer's disaster story

#124

Post by carapace »

madeofpalk wrote: post #59
XorNot wrote: post #37

The "curmudgeon" ending line in this story rubs me the wrong way. The ObjC people were right, basically, and it seems like the problem was essentially no one in the right place was going to drop Swift at that point. Seems less like they weren't offering answers, so much as the answer wasn't "but we'll do some stuff and fix Swift!" Though the 6 library limit and how that wasn't a gigantic red flag on the language is b…

We won't know because all we have is one glib comment from one person, but I took the comment on face value. I've definitely met the class of developer who is mainly interested in pointing out problems and a stick in the mud, and isnt interested in working together on solutions.

Yeah, but what are the odds of Uber having hired a whole raft of that class of dev?

Re: A former Uber engineer's disaster story

#126

Post by didip »

pjc50 wrote: post #60

This may be an egregious question, but what does the Uber app actually do that makes it so big? It displays a map with some moving dots on them, allows you to pick a location, and asks the server for a route and price. Plus a bit of workflow for signup, credit card, reviews; not a huge number of screens. I appreciate the difficulties of getting an app to fit in a fixed space having worked on a point of sale system th…

I have to say, this comment is quite ridiculous. Might as well say that Google is simple because it's just an app with one search field.

I never work for Uber but I can easily imagine the following problems:

* Map data is not a solved problem. Tons of inaccurate data especially on non-english speaking countries.

* As someone mentioned about payments, different country requires different payment platform integrations.

* Payment is just one aspect of money, you need to build a treasure-like logic to run a marketplace between drivers and passengers.

* The matchmaking algorithm itself is interesting enough problem. It has to be efficient for the company to make the most amount of money.

* Tons of internal data are produced and required to be understood. This requires ML/data analytic talents.

Re: A former Uber engineer's disaster story

#127

Post by kfarr »

pjc50 wrote: post #60

This may be an egregious question, but what does the Uber app actually do that makes it so big? It displays a map with some moving dots on them, allows you to pick a location, and asks the server for a route and price. Plus a bit of workflow for signup, credit card, reviews; not a huge number of screens. I appreciate the difficulties of getting an app to fit in a fixed space having worked on a point of sale system th…

A negative / unpopular take: like air in a balloon a startup company will grow as large as its capital allows as it is purposefully using this capital to grow faster than natural market forces allow. In other words it has a big engineering team because it raised capital to get a big engineering team. Craigslist is a great example of bucking the trend in this regard.

A more positive take: if you look at the specifics of how many regions Uber is (was) in, and that each region has cities each of which have wildly different regulatory environments, you can imagine the permutations of complexity they had to deal with. Then you add in growing internal business experiments like Eats or mobility (Jump) and it's easy to see how this balloons out of control pretty fast.

Re: A former Uber engineer's disaster story

#128

Post by CountHackulus »

nwsm wrote: post #14

Great thread. > So said brilliant engineer in Amsterdam, built an annealing algorithm in the release build to reorder the optimization passes in such a way to as minimize size. This shaved a whooping 11 mbs off the total machine code size and bought us enough runway to keep development going. > This terrified the Swift compiler engineers, they were worried that untested complier pass orders would expose untested bugs…

> > This terrified the Swift compiler engineers, they were worried that untested complier pass orders would expose untested bugs

> This would scare me too.

For what it's worth a few (10ish) years ago we did this with the J9 compiler at IBM (technically just the backed that was shared between Java, C++, etc). Same idea with simulated annealing. It did end up finding some really strange bugs, but they were bugs that were present regardless, we just hadn't found the right test case for it. We did end up getting some performance out of it, but not nearly as much as you'd expect. It mostly boiled down to running a few extra constant folding passes.

Re: A former Uber engineer's disaster story

#129

Post by saagarjha »

dntrkv wrote: post #108
lock-free wrote: post #81

Earlier quoted context omitted.

There are a lot of ways to frame these problems as interesting algorithms but it doesn't really strike me as something that is troubled by scale. I've worked on similar problems where "everything is a special case" in some vein and it takes a few very clever minds to construct the algorithms and datastructures that can come to a good solution. But that's just it, it's the work of a few engineers and not thousands wri…

A good place to start would be to go through the Uber UI and click through every button and every page that exists. Now create a driver profile and do the same thing. Now create the multitude of other special profiles they have and do the same. Now do the same for Uber Eats. Now do the same for Eats but using the restaurants version of the app. And the couriers. Now get in on Uber Freight (and any other projects they…

This is a common but specious argument. It is possible to make large, complicated apps without creating a monstrosity. That you are making something like this is a manifestation of an engineering culture that has too many cooks in the kitchen, a lack of specific engineering talent spent on finding issues and telling the teams shipping them to stop, people shipping libraries that they don't need and tech debt that was never pruned away. An app with 100x more people working on it should not be 100x larger, because it certainly won't have 100x more features in it. Sure, Uber is more than "a map and a couple views" but the fact remains that their app should never have been in the state that it was.

Re: A former Uber engineer's disaster story

#130

Post by grahamburger »

didip wrote: post #126
pjc50 wrote: post #60

This may be an egregious question, but what does the Uber app actually do that makes it so big? It displays a map with some moving dots on them, allows you to pick a location, and asks the server for a route and price. Plus a bit of workflow for signup, credit card, reviews; not a huge number of screens. I appreciate the difficulties of getting an app to fit in a fixed space having worked on a point of sale system th…

I have to say, this comment is quite ridiculous. Might as well say that Google is simple because it's just an app with one search field. I never work for Uber but I can easily imagine the following problems: * Map data is not a solved problem. Tons of inaccurate data especially on non-english speaking countries. * As someone mentioned about payments, different country requires different payment platform integrations.…

The items you've listed don't appear to be things that would contribute directly to the size (in MB as installed on the device) of the app. I don't think GP was making a comment about the complexity of the product, just the size of the installed app.
Post reply on HN