The interaction surface usually is just tip of the iceberg.

Here's a thread [0] regarding the complexity of Uber's iOS app.

Dan Luu made a far better case [1][2] for this than I could. Worth the read.

0: https://threadreaderapp.com/thread/1336890442768547845.html

1: http://danluu.com/sounds-easy/

2: https://twitter.com/danluu/status/782974159156502534?lang=en

When FB went public, they made money and had 3-4k employees, Google were pretty similar.

I don't object to lots of employees in principle, but coupled with losing money every single quarter, it's a red flag for me.

Uber is complex, that’s for sure. It’s not a job for 10 people team. But they also suffer from not invented here syndrome and blow up amount of work needed.

That’s not unique to them. Lots of Silicon Valley companies have engineering teams seeded with folks who worked whole life at Google, Facebook, etc. They default to writing custom solutions for everything, because that’s what they were taught.

> They default to writing custom solutions for everything, because that’s what they were taught.

I can only speak regarding my experience at Google, but the company has been moving aggressively toward industry standards for software development, primarily at the language level.

I constantly run see internal libraries in C++ being updated to use standard C++ smart pointer types, and Java being updated to use types like java.lang.Instant instead of some internal implementation created years ago.

What does tend to be custom are the systems that get built, not only because of the huge scale of operation, but also because of Google-specific security and compliance requirements. Also, the development tools and continuous integration systems are also necessarily specific to Google (and are pretty amazing).

But even then, there is extensive use of certain externally originating systems - memcached is one that comes to mind.

> I can only speak regarding my experience at Google, but the company has been moving aggressively toward industry standards for software development, primarily at the language level.

Why now? What were technical reasons this wasn’t done before at Google?

In some cases, the outside world hadn’t settled on a standard when the code was first written, or it wasn’t that good yet.

Exactly. For example, like many companies, Google had smart pointer implementations in its C++ codebase almost from its inception, but they didn't appear in the C++ standard until C++11.

We shouldn't ignore the fact that Uber has been going for 11 years though. That's a lot of time to build all that functionality and iterate it to be good. A small team of competent devs could build everything in the comment you linked to in a little over a decade. Probably a lot less.

Build? Sure.

Build well? These things aren't built perfectly the first time, or anywhere close. You don't always know what you're building until you've iterated on it a few times. It's just ready to forget that you didn't know when you have the benefit of hindsight.

And build well and maintain? Not a chance. This should be obvious.

Maybe we have different ideas off what a small team is. To be, 3-4 devs is a small team. In context, I could say maybe ten developers, but I would consider that a large team. At that point I'd be preparing to split into multiple teams.

In not saying they needed 21,000, but it's likely we just mean completely different things when we talk about a small team. What does it mean to you?

I guess you missed the word "iterate" in my post. Good software doesn't spring in to existence just because a team has talent. It starts off OK if you're lucky and it evolves in to something good if the team can guide it properly.

I'll ask again, when you say a small team, what exactly are you thinking about? Order of magnitude is fine. 3? 30? 300?

That is a great explanation. It’s to Uber’s credit that their app seems so deceptively simple. That said all those special cases make me even more skeptical about them getting on the right side of profitability.

Every one of those localized special cases that Uber puts a team on is them defending a moat against localized competitors. For the upstart localized app, that country’s payment system, driver laws, airport rules etc more similar to the basic 5 screen app Uber seems to be.

Anytime Uber let’s it’s foot off the gas in a particular place one of those will show up, offer drivers a slightly better deal, and Uber will have to match - killing any margin.

What margin? They've never made a profit as far as I know. Maybe they'd make more money if they let these local competitors take their unprofitable business.

This is interesting detail, but it doesn't sound like it requires hundreds of engineers. Most of this seems like relatively common functionality (processing payments) with heavy regionalization. None of this is cutting edge work. Knowledge resources and experienced people would be widely available for all of it. It seems hard to understand why maintaining this system, even with the number of locations and users, would require more than 100 pure software engineers (thinking ~10 teams of 10, at most).

I'm never sure how much Parkinson's Law is at play with startup hiring in general. But I guess most engineers they hire provide value to the company at least equivalent to their salary.