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

151–160 of 344 posts

Re: A former Uber engineer's disaster story

#151

Post by pavlov »

saagarjha wrote: post #98
pavlov wrote: post #4

Apple's botched introduction of Swift is easily responsible for billions of dollars in lost productivity across the industry since 2014.

"Botched introduction, really? Perhaps Apple could have been a bit more upfront about the state of the tooling (which, of course, they never will be) but I think they did a rather good job considering that they moved development out from "total secrecy" to "community-involved" within two years, all the while shipping new features and improvements to the experience at a fairly decent pace.

> “which, of course, they never will be”

That’s the problem. Apple knows by now that their developer community laps up absolutely everything they put out and regularly gets burned. (I’m old enough to have rewritten code for Cocoa Bindings in 2004. It’s the next big thing! And garbage collection in 2008. It will fix everything! And GCD... and...)

For such an enormous change as Swift, they should have switched off the reality distortion field, and gone with a more sober, more academic approach.

Re: A former Uber engineer's disaster story

#152

Post by lhorie »

saagarjha wrote: post #145
gregdoesit wrote: post #93

Earlier quoted context omitted.

Former Uber engineer/EM here: I worked on the Rider app. The “there are only a few screens” is not true. The app works in 60+ countries, with features shipped in the app that often for a country, and - in rare cases - a city. The app has thousands of scenarios. It speaks to good design that each user thinks the user is there to support their 5 use cases, not showing all the other use cases (that are often regional or…

Look, I get it that the app is complicated. I look at these apps from the perspective of a reverse engineer but invariably I find places where there is bloat just for the sake of being bloat. There is code that is provably not used, entire libraries that included just so that one small part of it can be used. I see time-related assets that have existed long past the date that they could have possibly been useful. I h…

Eh. It doesn't seem particularly relevant to bring up Linux, with its hundreds of thousands of person-hours worth of volunteer contributions and an extremely technically focused BDFL gatekeeper.

It's a relatively well known fact that multi-team corporate projects have tech debt. There was a thread recently about Google Cloud being slow due to too-many-cooks-in-the-kitchen syndrome, and many ex-amazon folks say AWS UI is notoriously difficult to refactor for similar reasons.

Re: A former Uber engineer's disaster story

#153

Post by saagarjha »

wsinks wrote: post #143
saagarjha wrote: post #129

Earlier quoted context omitted.

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…

For my own curiosity, what large, complicated apps are not monstrosities in your eyes?

The Apple Maps app on iPhone, for example? If you make it fair and count the code that goes into the frameworks specifically for it, it's still tens of megabytes at the most. There is a huge part of it running server-side to support it, of course, but it is difficult to say that it is not a complicated app. Or consider the Mail app? It needs to deal with IMAP, and has custom flows for a number of named mail services (Gmail, Yahoo, etc.), and then it has to have special code to handle all the edge cases of "what happens if the user deletes a message here but it didn't sync, or Google sends us 503s sometimes if we do this, or…" You can make arguments that maybe it is slightly less or more complex than Uber, but it is just a couple dozen megabytes and not hundreds.

Re: A former Uber engineer's disaster story

#154

Post by saagarjha »

sethammons wrote: post #150
lhorie wrote: post #148

Earlier quoted context omitted.

Uber actually has a not-so-well-known product for this very problem: the mobile web version (m.uber.com) It doesn't have nearly as much functionality as gregdoesit mentioned, but it's enough to service the use case of getting you from point A to point B when you're stuck w/ crappy connectivity.

Wow, I had no idea! On app load, maybe checking speed and then displaying a link to the web version for low bandwidth areas would be a good move.

Why display a link? Hybrid web/native apps are a tried-and-true strategy when you have massive complexity or dynamic content that you don't want to ship with your app. If you use it judiciously and tastefully the "native UI everything" people don't notice and come after you, either.

Re: A former Uber engineer's disaster story

#155

Post by kingnothing »

lhorie wrote: post #148
oefrha wrote: post #96

Earlier quoted context omitted.

Yet, the last time I was throttled to 2G speed due to a problem with my carrier, the Uber app couldn’t even start (getting to the first interactive screen) in like five minutes. What’s the point of distributing the entire world’s data, which gotta change from time to time, when you can download the tiny requisite piece each time, especially considering that a relatively high speed Internet connection is required to u…

Uber actually has a not-so-well-known product for this very problem: the mobile web version (m.uber.com) It doesn't have nearly as much functionality as gregdoesit mentioned, but it's enough to service the use case of getting you from point A to point B when you're stuck w/ crappy connectivity.

The other not-so-well-known product is the Uber Lite app (iOS and Android) which was specifically made by Uber for this problem, particularly in the developing world.

Re: A former Uber engineer's disaster story

#156

Post by saagarjha »

aaronbrethorst wrote: post #142
saagarjha wrote: post #97

Earlier quoted context omitted.

Large Swift apps are easy to find; companies would invariably use it as a marketing point on their engineering blog. Even if not, people open up apps all the time, any large app that uses Swift would be found and discussed.

Large Swift apps are easy to find Sure, if they exist. I'm not talking about the world as it is today in December 2020 with Swift 5.3. I'm talking about 2016.

My point was that there was no need to ask Chris Lattner back in 2016: you could just look around the landscape and see that there were not many, as they would be easy to see if they did exist.

Re: A former Uber engineer's disaster story

#157

Post by Apocryphon »

lhorie wrote: post #152
saagarjha wrote: post #145

Earlier quoted context omitted.

Look, I get it that the app is complicated. I look at these apps from the perspective of a reverse engineer but invariably I find places where there is bloat just for the sake of being bloat. There is code that is provably not used, entire libraries that included just so that one small part of it can be used. I see time-related assets that have existed long past the date that they could have possibly been useful. I h…

Eh. It doesn't seem particularly relevant to bring up Linux, with its hundreds of thousands of person-hours worth of volunteer contributions and an extremely technically focused BDFL gatekeeper. It's a relatively well known fact that multi-team corporate projects have tech debt. There was a thread recently about Google Cloud being slow due to too-many-cooks-in-the-kitchen syndrome, and many ex-amazon folks say AWS UI…

The Grand Bazaar of Istanbul and the Tower of Babel.

Re: A former Uber engineer's disaster story

#159

Post by saagarjha »

lern_too_spel wrote: post #136
saagarjha wrote: post #87

Earlier quoted context omitted.

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.

That is true, but what specifically is the iOS app getting in that extra quarter gigabyte? What couldn't they throw away to get under 200 MB at all?

I honestly have not been provided with a good answer beyond "we just didn't spent resources to do it".

Re: A former Uber engineer's disaster story

#160

Post by sethammons »

gregdoesit wrote: post #93
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…

Former Uber engineer/EM here: I worked on the Rider app. The “there are only a few screens” is not true. The app works in 60+ countries, with features shipped in the app that often for a country, and - in rare cases - a city. The app has thousands of scenarios. It speaks to good design that each user thinks the user is there to support their 5 use cases, not showing all the other use cases (that are often regional or…

I am not an app developer, so ignorant. Why not have different apps? Uber-India, Uber-Mexico, etc? Or if it is to be all one Global Uber app, why not have expansions that are downloaded for other regions as needed?
Post reply on HN