Gone are the days where Twitter body limit was understood as the reason to post short tweets instead of long tales...
A former Uber engineer's disaster story
311–320 of 344 posts
Re: A former Uber engineer's disaster story
#312Gone are the days where Twitter body limit was understood as the reason to post short tweets instead of long tales...
Works well in ThreadReader though: https://threadreaderapp.com/thread/1336890442768547845.html
Re: A former Uber engineer's disaster story
#313Gone are the days where Twitter body limit was understood as the reason to post short tweets instead of long tales...
I know right. I was even more disheartened when someone who I thought might be mature enough and understand the modern internet also used Twitter instead of their own blog to write a series of tweets as a blog, Cory Doctorow.
I refuse to go to Twitter to read such stuff (threadreader is not a justification, it's a crappy workaround) and fully endorse the communication of the idea that it sucks.
Re: A former Uber engineer's disaster story
#314Earlier quoted context omitted.
How do you know all these facts about the Uber app? Can you inspect the binary?
Parts of the binary on the App Store are encrypted so we can only get limited information from it, but the whole app bundle is available and the rest of the files are not encrypted. We’re building a startup to help monitor, analyze and reduce app size and I was able to quickly grab these statistics from the tool we’re working on, here’s a link to a quick demo: https://www.youtube.com/watch?v=3x-hLxxUNm8
It is also quite easy to decrypt iOS applications using jailbroken devices.
Re: A former Uber engineer's disaster story
#315Former Uber employee. I can corroborate much of what they say (not having been on those sorts of teams). The depiction of the company culture is accurate.
Re: A former Uber engineer's disaster story
#316Many engineering horror stories involve an entire system rewrite. My recommendation is to never rewrite a large system. Literally never. If the people proposing the rewrite aren’t capable of adding the features incrementally, they aren’t capable of rewriting the entire system to “easily” support those new features.
I've spent most of my career doing rewrites, each time reluctantly, and each time it was a resounding success. So easy with the absolutes :-)
Point taken but something tells me we might have different ideas about what it means for a rewrite to succeed.
Re: A former Uber engineer's disaster story
#317This 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…
Was just about to link to your tweet on this subject from the other day. You saved me the search!
Re: A former Uber engineer's disaster story
#318Earlier quoted context omitted.
I mean, Uber has had a huge number of people working on it too, with the incentive that they are paid to do a good job. Regardless of the eventual outcome, I have no misconceptions that Uber doesn't have some engineers who are extraordinary talented. And, the project is newer, too, with fewer guarantees on stability and fewer users to boot. I think it's a valid comparison to make at least–they are both huge, complex…
To be clear, I do think you have a valid point about e.g. unused assets and loading big libs to do trivial things, but IMHO, that's really a commentary on software development at large, rather than anything specific to Uber. And there are cases, even in the Uber app, where thought has been put into optimizing both for upfront download size and internal complexity (the legal pages, for example) Something that is worth…
What I don't really understand is why so much of the dynamic content ends up being native code on the client. For example, let's say you need to have some of legal compliance page. But there is always changes you have to make in a bunch of regions, and the flow is constantly changing, or whatever. But why can't this be a DSL you download and deserialize into views? Why does there have to be a hundred different native views for this that all must be part of the app? I'm hearing all these tail-end cases that one region hits and interacts with for seconds and I guess I don't really understand why these things are not handled server-side, making the app a dumb client. After all, isn't that how the website surely works?
I understand that Linux doesn't necessarily always have the product marketing deadlines or whatnot that Uber might have, but it's saddled with legacy code too. When things have security issues, or the API is just awful, at some point someone needs to fix it. Especially if your business is being decimated by a bug or you are lacking in APIs that meet your usecase. I don't think it's as poor as a comparison as you might thing it is.
Re: A former Uber engineer's disaster story
#319Earlier quoted context omitted.
I mean, Uber has had a huge number of people working on it too, with the incentive that they are paid to do a good job. Regardless of the eventual outcome, I have no misconceptions that Uber doesn't have some engineers who are extraordinary talented. And, the project is newer, too, with fewer guarantees on stability and fewer users to boot. I think it's a valid comparison to make at least–they are both huge, complex…
I think the argument is more that even if you were to magically get rid of the cruft introduced by institutional bloat, the app will still necessarily be large given the nature of the business. Uber isn't some outlier here either; Lyft, Ola, Yandex, GoJek, Grab, etc etc all have comparable iOS app sizes.
It sounds stupid, but I'm going to say that they're all doing it wrong. One commenter in this thread brought up the Uber app for Android and it's a fraction of the size–clearly, market constraints can make it possible to do better?
Re: A former Uber engineer's disaster story
#320Earlier quoted context omitted.
Looking at the bundle now is not going to give you insight into the problems in the Uber app 4 years ago. Also you’re looking at the uncompressed install size, which was not the problem (over the air compressed download size was the limiting factor). Strings files are extremely compressible, encrypted binaries are not (Apple has done some work in subsequent years to make them more compressible but back then they were…
Absolutely right! I left out some details to try to keep the post concise. 4 years ago at Airbnb we had the watch app problem, but now a Swift watch app wouldn’t be an issue since the latest OSs don’t require embedded Swift standard libraries. The tweet that started this thread cited the 300+mb size of Uber’s app, which looks like the current install size (not thinned), that’s why I used it as the benchmark in my exp…
Yes, installed size is also an issue. And on iOS tens of thousands of small files will waste a lot of space. One may say that compared to photos and videos that's small potatoes but I disagree. Efficient use of resources, memory, bandwidth, battery, etc. matters.