Hacker News new | ask | show | jobs
by dsr_ 1485 days ago
You're missing roughly 30,000 employees to run a service that, at steady state, probably needs about 30 software developers and a few hundred second or third level customer support folks, with first level being handled by outsourced local-language companies.

And then there's Uber self-driving. Uber AI; Uber electric airplanes. Uber freight, Uber restaurant delivery, Uber grocery delivery, Uber this and Uber that. Oh, and Uber scooters.

7 comments

The Uber app alone would probably need much more than 30 developers, see here : https://news.ycombinator.com/item?id=25376346
A lot of that is optional complexity, though.

Uber eats? Scooter integration? Mass transit support? Scheduled rides? Commuter cards? If you were building the app with 30 developers you'd simply not bother with those features.

I can only see giving up on Uber Eats as being foolhardy, that is a profitable business with a solid business case, yet lacking those other features would not really cause me to prefer traditional taxicabs telephone dispatch over using an app.

There's legitimately a reasonable argument that Uber rides has a worse business case than Uber Eats. If I were in Uber's shoes I would be clinging onto both.

Delivering time sensitive goods from many locations to many other locations is not an easy business model. Especially when you do not control the provider of the sensitive goods or the delivery provider.

Logistics is a tough business so I’m bearish on Uber eats.

> that is a profitable business with a solid business case

I reaaaaly wouldn’t assume its a profitable business unless you get some data from a few “normal” (i.e., not pandemic impacted) quarters.

Delivery is the first thing people will cut down on if we get a recession as well

Isn’t Uber Eats their most profitable business.

At least that’s what Uber recruiters would tell me when trying to recruit.

Most profitable business for an overall loss making company doesn't say much.
Why are you ignoring the regional differences & the other stuff listed above those points in that post?
Companies like eBay have a global footprint and send/receive money in dozens of countries. eBay has apps for all devices and a website.

Uber has 3x the headcount as eBay.

eBay looks like a platform that is at least an order of magnitude simpler: No realtime data streams like GPS updates, no matching algorithms, no demand-based pricing or incentives, no ETA calculations. Uber is operating in the real world which means that weather, traffic, protests, construction, events and so on affect the operation.

The eBay business requires no boots on the ground, Uber Eats does because they have to equip riders. And eBay has almost no market-specific laws/regulations which change every couple of months to worry about.

I think eBay doesn't process payments, that is outsourced to PayPal.

It looks like eBay is in about 25 markets, Uber is available in 85 countries.

Serious question: Why does eBay have so many employees? It's just a search engine for a user generated product catalog where users can place bids on the items. My guess is that most Uber employees aren't high-paid developers, it is more likely that they are in support roles.

eBay handles their own payments for a while now. PayPal is still an option, but sellers are required to register a bank account with eBay.
eBay can get away with relying on third parties for advertising, selling, and transporting goods. They are just an online marketplace.

Uber has to market themselves which needs local expertise, if nothing else to liaise with a local PR firm. Then they need local legal expertise to actually operate in the country (eBay transactions happen online, and the transport agency hired by the seller figures out how to get the package to its destination). Uber then has to have maps for every country it operates in, as well as change their standards to match local expectations.

eBay is arguably a bad example because they sure could do with a proper overhaul of their software that is halfway modenised with a bunch of rough edges accumulated over decades.
I will agree that 'receipts' is part of the core product and should be retained. I didn't mention it because I'm sure we can agree it's within the capabilities of a 30-person team!

I ignored the other stuff because I don't know WTF "pickup special cases" or "on-trip experience business logic" or "growth features" are. So I'm not informed enough to guarantee they aren't part of the core product offering - although you can probably guess my intuition on the matter.

This kind of "how hard could it be" analysis is what causes people espousing it to go surprised-Pikachu-face when their nose is ground into fractal complexity requirements. The closer to the coalface you get, the more "huh, who would have thought?" is murmured. A huge chunk of this comes from only thinking about happy path logic in one setting.

The software that runs the world and gets actual work done day-in, day-out behind the scenes, is riddled with edge case handling. In really mature codebases impacting many stakeholders (not just direct users), the product team can categorize 1% or less of the stakeholder population by a tiny fraction of a commonly-used feature set they use. On that basis, the coding and maintenance effort for the edge cases can sometimes outweigh the sliver of features used by that sub-population of stakeholders.

We aren't talking about a web scraper or run of the mill DevOps here. Anytime you work with lots of business rules in multiple jurisdictions impacting the same processes, the edge case counts go up rapidly, and combinations of processes that you never thought would intersect but are forced to by specific jurisdictions also appear more frequently.

I mean this is still arguing over 3 orders of magnitude difference in employee count though. Uber is incredibly heavy on non-"provides a ride from point A to point B" compensations.
That's interesting. Because of the aggressive expansion from VC money they now have too much bloat making it more difficult to be profitable.
Scheduled rides are sort of important where driver availability is low. Not everyone is in a major city.
Scheduled rides never actually allocates a driver for me; just a time range and it books a normal ride right when that range starts. Then the driver comes late!
Just like Twitter is one guy hacking on RoR for two days... we've heard this old canard before.
Whatsapp used to service 900 million users with literally 50 engineers. Instagram had 13 employees when it was acquired. The old canard is true if you focus on a core product and make smart architectural choices. (in Whatsapp's case they credit a lot of their efficiency to Erlang).

[1]https://www.wired.com/2015/09/whatsapp-serves-900-million-us...

Simplistic messaging apps aren’t really a good model to run off of. Designing WhatsApp and Instagram are common system design questions because they’re trivial in comparison to design Uber/Lyft, etc.
Even Waze isn't complex enough to compare with Uber. Waze has to process real time data but doesn't have to deal with processing payments and complying to regulations worldwide.
Could it be that introducing compliance at a later stage in development is just that much more expensive?

That's after shitting on compliance for years as part of your business model.

Don't conflate scale complexity with business complexity
There's a bunch of reasons why this model doesn't hold up in the long run, and I'll give one of them: accessibility. Once your business decides that your app must be sufficiently accessible to reach the many people who need accessibility work, your backlog explodes.
So ignore accessibility. It's not a legal requirement and it doesn't pay.

McDonald's restaurants have handicap accessible ramps but they don't staff ESL speakers. Apps and web services are no different.

Clubhouse, for example, isn't accessible to the hearing impaired and that's ok.

Technically it isn't: if you run an American business, you are subject to the Americans With Disabilities act as it is pursuant to electronic services [1].

Uber specifically would definitely fall under a "public transportation" service - accessibility is non-optional if someone decides to sue. [2]

[1] https://www.ada.gov/2010ADAstandards_index.htm

[2] https://www.businessnewsdaily.com/10900-ada-website-requirem...

>> So ignore accessibility. It's not a legal requirement and it doesn't pay.

Firstly that is just plain incorrect in a lot of areas (of business) and jurisdictions. Secondly your outlook on accessibility is just ... SMH and walks away from keyboard.

says who? accessibility is not that hard to achieve if you know what you're doing and make efforts from the very beginning to build your product in an accessible fashion
The problem is that accessibility is not a common high priority requirement for most software, making people with accessibility experience rare.
Show me a single piece of successful software that didn't suffer the "new business requirement upends everything about how we built it" problem.
And MS Notepad is servicing billions of people with one engineer.

Do you think complexity of Uber is comparable to that of Whatsapp?

>> Whatsapp used to service 900 million users with literally 50 engineers. Instagram had 13 employees when it was acquired.

There is a big difference here -- revenue. Real transactions. Financial reporting. Country-by-country regulations and reg reporting.

Yes, it would be impossible to do something as complex as the Uber app with only 10,000 employees. Better to run the company into the ground.
It’s just some text on the web! And they wonder why software engineers are bad at estimates
> 30 software developers

- iOS rider app

- android rider app

- iOS driver app

- android driver app

- ride/driver matching

- routing/supply

- security/compliance

- fraud detection/prevention

- backend rides services

- backend user services

^ 10 teams of at least 10 people off the top of my head. Amazing how underestimated engineering resourcing needs are.

Plus all the back end billing and payments, including integration with some third-party enterprise expense management systems.
If it only was so easy …
Well, the google results when I initially posted it didn't even bring up the choice I would probably use (again). Which is C++ and either a custom hand rolled platform abstraction layer, or maybe something like QT if the application were UI heavy. Which from what I can see of the uber app isn't.

That is because its very well supported on both platforms, and one of the few language ecosystems that can actually create native looking/acting applications on both.

Yes, the initial development may be a bit slower, but that is common with C++ because what the smart people are doing is usually creating an application specific "language" out of C++. Then once that core bit is done the actual development would probably outpace many of the other choices. I've done this a couple times with native development toolkits, the "customer" in one case was really questioning how much work was actually going on when 1/2 way through the contract it barely had a single "screen" in a data collection/reporting application working. But, then another few weeks went by, and literally in the space of about 2 days the application went from looking like it had just been started, to being basically feature complete. That is because the C++ engine was complete and it took ~12 hours to fill out the few 10s of thousands lines of boilerplate ui descriptions that actually formed the UI (in that case it was a custom textish/declaritive application description language, most of the c++ code was parsing it and doing layout/drawing in response. Super happy customer too, once they understood that their inhouse "IT" people could update/change the app with little more than a text editor against some fairly simple to understand rules).

And many of the functions the GP was asking about are the kinds of things one could contract out. Aka, why not just use google maps API for the routing/etc.

Frankly, given what I saw a couple years ago when I went poking around in the iphone app store, it seems just about every region taxi company had reimplemented large parts of the uber interface in their own apps. Maybe not always as slick, but the core parts were in many of them, and I doubt random regional taxi companies can afford the engineering effort uber apparently is spending on.

IIUC, Uber employs 2000 engineers. I'm not sure how that's only 6% of the company.

If you're looking to trim fat - surprisingly - there might be better opportunities outside of engineering.

>> You're missing roughly 30,000 employees to run a service that, at steady state, probably needs about 30 software developers and a few hundred second or third level customer support folks, with first level being handled by outsourced local-language companies.

This comment is insane for any real app in the real world transacting in real dollars. There are a hundred countries with 100 regulations. Accounting/P&L/bookkeeping for the United States ALONE would take 30 developers for a revenue base this size.

FWIW Uber sold its autonomous vehicle research division in 2020. https://www.npr.org/2020/12/08/944337751/uber-sells-its-auto...
LOL. Just regulatory compliance will be more than 30 software engineers.