Live data from Hacker News

A former Uber engineer's disaster story

twitter.com

81–90 of 344 posts

Re: A former Uber engineer's disaster story

#81
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…

Follow-on tweets address this somewhat: Every airport has different pickup locations, every region has different payment rules including cash, etc. Apparently all this location-specific business logic has to be in the app itself and is not downloadable on demand.

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 writing if-else blocks for each airport.

I still don't understand what Uber does that requires so many people getting paid so much money, the only thing that makes sense to me is they don't want them working for Lyft. It would be helpful for people to shed more light on how engineering resources are spent and what particular systems require so many hands to realize, but that's too valuable information to leak I'd imagine.

Re: A former Uber engineer's disaster story

#82
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…

Follow-on tweets address this somewhat: Every airport has different pickup locations, every region has different payment rules including cash, etc. Apparently all this location-specific business logic has to be in the app itself and is not downloadable on demand.

Seems like a reasonable architectural choice early on when your app is live in 2 cities. Instead of changing the language of the app, they should have focused on its API architecture.

Re: A former Uber engineer's disaster story

#83
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…

>This may be an egregious question, but what does the Uber app actually do that makes it so big?

It justifies the employment of 400 iOS engineers, it also lets you book taxi rides.

Re: A former Uber engineer's disaster story

#84
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…

Yeah it’s kind of bizarre that after writing everything leading up to that, the author would still frame the ObjC folks in that way. Like, this or that eng. was so brilliant with their hack, but all those obj-c eng. who advocated boring but stable solutions all along were just curmudgeons with no helpful advice.

The problem from the author's perspective is that the Obj-C "curmudgeons" were proving the right solution to save the app (drop Swift and cut losses + go back to a functioning language) but not the careers of the people who had gotten them into this terrible situation.

Re: A former Uber engineer's disaster story

#85
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…

Yeah it’s kind of bizarre that after writing everything leading up to that, the author would still frame the ObjC folks in that way. Like, this or that eng. was so brilliant with their hack, but all those obj-c eng. who advocated boring but stable solutions all along were just curmudgeons with no helpful advice.

Sounded like a "both sides" analysis, where the assumption is that both sides in a disagreement must share blame.

Re: A former Uber engineer's disaster story

#87

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?

I assume that the constraints placed on the Android team are much higher, as that market seems like it would be much more sensitive of app sizes.

Re: A former Uber engineer's disaster story

#88

I've lost track of the number of "biggest engineering disaster" stories I've read that begin "so we decided to rewrite it..." The story arc is almost always the same: starts out very promising and moves quickly, then at some point the wheels come off but everyone keeps going. Anyway, Joel Spolsky nailed it 20 years ago: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Couple things always to mind whenever this article is referenced.

Joel's example is Mozilla, but Mozilla ultimately became more successful than Netscape (in terms of userbase with Firefox). Was the problem really the rewrite, or that a browser company was doomed anyway and the rewrite exacerbated it?

Also the article was published just a year before Microsoft pulled off what's maybe the most successful large rewrite and customer migration in software history: Windows/DOS to Windows NT (XP was where it became complete).

I've always wished for Joel's take on NT, especially since he was at Microsoft previously and it happened just after this article was posted. What's his opinion on its success when so many weren't?

Re: A former Uber engineer's disaster story

#90
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…

Experimentation / data-driven product development. You’re actually downloading 583 small variations of the same app, plus all the localized rules mentioned above, and it quickly adds up.
Post reply on HN