In almost 20 years of working in FinTech at various banks, hedge funds startup etc, a lot of this rings true.
e.g.
- Critical path/flow diagrams [0] are incredibly useful for both laying out what has to happen in serial vs what can be parallelized. That being said, I've almost NEVER seen them used and 90% of the time they are used it's b/c I made one
- SO many important processes are not documented so people can't even opine about how to fix them. I once documented a process and everyone agreed step 4 was wrong. What was amazing is no one agreed on what step 4 actually was.
- Most of the big arguments I've seen about projects are less "what should we do" but more "when do we want it" e.g. one party want's it next week but another one wants to have more features so it will take longer. [1] I've often dealt with this by using the following metaphor:
"Oh, so you want to move house every two weeks?
If you give me six months I'll build you the world's most amazing Winnebago/RV with a hot tub, satellite TV, queen size bed and A/C.
If you want it tomorrow I'm going to give you a wheelbarrow, pillow and an iPad."
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 just not relevant to the type if user - like business traveler use cases).
Uber builds and experiments with custom features all the time. An experimental screen built for London, UK would be part of the app. Multiply this by the 40-50 product teams building various features and experiments outside the core flows you are talking about (which core flows are slightly different per region as well).
I worked on payments, and this is what screens and components are in the Uber app:
- Credit cards (yes, this is only a a few screens)
- Apple Pay / Google Pay on respective platforms
- PayPal (SDK)
- Venmo (SDK)
- PayTM (15+ screens)
- Special screens for India credit cards and 2FA, EU credit cards and SCA, Brazil combo cards and custom logic
- Cash (several touch points)
- AMEX rewards and other credit card rewards (several screens)
- Uber credits & top-ups (several screens)
- UPI SDK (India)
- We used to have Campus Cards (10 screens), Airtel Money (5), Alipay (a few more), Google Wallet (a few) and I other payment methods I forget about. All with native screens. Still with me? This was just payments. The part where most people assume “oh, it’s just a credit card screen”. Or people in India assume “oh it’s just UPI and PayTM”. Or people in Mexico “oh, it’s just cash”. And so on.
Then you have other features that have their own business logic and similar depths behind the scenes when you need to make them work for 60 countries:
- Airport pickup (lots of specific rules per region)
- Scheduled rides
- Commmuter card functionality
- Product types (there are SO many of these with special UI, from disabled vehicles, vans, mass transport in a few regions etc)
- Uber for Business (LOTS of touchpoints)
- On-trip experience business logic
- Pickup special cases
- Safety toolkit (have you seen it? Very neat features!)
- Receipts
- Custom fraud features for certain regions
- Customer support flows
- Regional business logic: growth features for the like of India, Brazil and other regions.
- Uber Eats touchpoints
- Uber Family
- Jump / Lime integrations (you can get bikes / scooters through the app)
- Transit functionality (seen it?)
- A bunch of others I won’t know about.
Much of the app “bloat” has to do with how business logic and screens need to be bundled in the binary, even if they are for another region. E.g. the UPI and PayTM SDKs were part of the app, despite only being used for India. Uber Transit was in a city or two when it launched, but it also shipped worldwide.
And then you have the binary size bloat with Swift that OP takes about.
The pattern maker who got the stripes to match in both dimensions probably used a textile CAD program to do it. There's software for this. High end: [1] Low end: [2]
"Pattern Design Software (PDS) 3D -- A set of 3D tools that display virtual samples in an innovative 3D digital environment that allows you to fashion your garment and make quick alterations at the click of a button, powered by photorealistic rendering for a true-to-life visualization."
"Inspect simulated cloth using a tension map to view the exact value of tension, distance, and stretch..."
These tools are also used for clothing for characters in games, movies, and virtual worlds. Marvelous Designer is often used for Second Life clothing.
e.g.
- Critical path/flow diagrams [0] are incredibly useful for both laying out what has to happen in serial vs what can be parallelized. That being said, I've almost NEVER seen them used and 90% of the time they are used it's b/c I made one
- SO many important processes are not documented so people can't even opine about how to fix them. I once documented a process and everyone agreed step 4 was wrong. What was amazing is no one agreed on what step 4 actually was.
- Most of the big arguments I've seen about projects are less "what should we do" but more "when do we want it" e.g. one party want's it next week but another one wants to have more features so it will take longer. [1] I've often dealt with this by using the following metaphor:
"Oh, so you want to move house every two weeks?
If you give me six months I'll build you the world's most amazing Winnebago/RV with a hot tub, satellite TV, queen size bed and A/C.
If you want it tomorrow I'm going to give you a wheelbarrow, pillow and an iPad."
0 - https://www.howtomakesenseofanymess.com/chapter3/67/2-flow-d... and https://www.howtomakesenseofanymess.com/chapter3/71/6-swim-l...
1- https://www.howtomakesenseofanymess.com/chapter3/51/reality-...