4 ms·

I love the "small team of focused engineers" trope for apps like uber. It's so easy to blow past that number. Website? That's a team. iPhone app? That's a team.

I love the "small team of focused engineers" trope for apps like uber. It's so easy to blow past that number. Website? That's a team. iPhone app? That's a team. Android? Another team. Data collection and A/B testing platform for all the front ends? Another team. Backend? A team. Infrastructure? Another team. AI solutions for problems like delivery time estimation? Another very expensive team. BI for the executives? You guessed it, another team!

csande17 4y ago
An underappreciated aspect of computer programming is that maintaining a program often requires less work than writing it in the first place. Once you finish writing the iPhone app, you've finished writing the iPhone app, and you can get by with a much smaller team--possibly just one person--to handle bugfixes and maintenance. Unicorn tech companies generally don't realize this, which is why they all redesign their apps over and over and add poorly-thought-out features all the time. They're still paying for a build-an-entire-iPhone-app-from-scratch-sized team, and all those engineers are desperately looking for stuff to do!
- iakh 4y ago
  You've never done iPhone development it seems where there's neverending new or deprecated versions of iOS and "kits". I've had clients that try this without a dedicated team, and each time was a nightmare for them(and hence us) where nobody remembered how anything was done
  - csande17 4y ago
    I have done iPhone development, and I can say with confidence that it is less work to take an iOS 17 app and update it to iOS 18 than it is to take nothing and create an iOS 18 app from scratch. You still need a non-zero number of people who know how the iOS app works, but the number you need is smaller.
- SNosTrAnDbLe 4y ago
  As long as you have good product requirements, creation is actually very simple. You have freedom to choose the technology and the tools. However, The moment that you discover that your AWS bill exceeds your engineering budget, you will have a different view of maintenance. People will now start calling it resilience, scale, optimization, etc. And then one day, the db will need to be partitioned (almost always, if the product is successful) and then the people who created the mess [almost always using a nosql database as it was available ]will run for the exits. You (or the poor unthanked ‘maintenance’ engineer ) will start learning about why distributed systems are hard to maintain.
- lazide 4y ago
  Oh, they realize it - which is why the managers and execs whose ongoing career trajectories require managing larger and larger orgs spend so much time coming up with more work! Most line engineers often realize it too pretty quickly, which is why we end up with so many new frameworks every time there is a huge boom cycle.
hotpotamus 4y ago
Fairly recently I moved from a company of about 8,000 to a company of 54 or so. At first I wondered how the tiny company got anything done, but they've been around for 30 years so I figured they must have some skill. Now I wonder what the hell all those 8,000 people actually did. Each team you just named is 1-2 people at the current gig.
- bogota 4y ago
  That really doesn’t say anything. Those teams all do very different thinks depending on the problem space. You’re not really making an argument though you are just stating two situations and hoping people arrive at your conclusion of big company is stupid.
  - hotpotamus 4y ago
    I think anyone who has interacted with a big organization (company, government, religion, etc...) comes to the conclusion that they're disfunctional in some way. I agree that it doesn't say much, but I do wonder, how many engineers built the original Uber app and how many does the company employee today? I'm betting it's more, and I wonder how much additional functionality they've added over the years.
- MonkeyMalarky 4y ago
  I work a startup with less than 15 technical employees and have experience at tech companies ranging from 100s to 100s of thousands of employees. Suggesting that one could accomplish or maintain a platform like uber with so few heads is a farce.
  - pclmulqdq 4y ago
    A team of 15 probably couldn't. A team of 50-100 probably could maintain something of similar complexity to the core uber app. Copycats exist using many fewer resources.
    - menzoic 4y ago
alkonaut 4y ago
These aren’t unique apps though. In my deregulated taxi market all taxi companies (dozens) have Uber functionality where you track cars on maps, pay via app, book rides in the app and so on. And many of the largest ones use the same app. Because they aren’t in that business, they are in the taxi business. If there is a margin to be found in scheduling or pricing, then their app supplier should provide it. This is perhaps what Uber should be doing: making the white label apps for local companies doing ride services. Not sure how many taxi markets are that unregulated that they allow it.

csande17 4y ago

An underappreciated aspect of computer programming is that maintaining a program often requires less work than writing it in the first place. Once you finish writing the iPhone app, you've finished writing the iPhone app, and you can get by with a much smaller team--possibly just one person--to handle bugfixes and maintenance. Unicorn tech companies generally don't realize this, which is why they all redesign their apps over and over and add poorly-thought-out features all the time. They're still paying for a build-an-entire-iPhone-app-from-scratch-sized team, and all those engineers are desperately looking for stuff to do!

iakh 4y ago
You've never done iPhone development it seems where there's neverending new or deprecated versions of iOS and "kits". I've had clients that try this without a dedicated team, and each time was a nightmare for them(and hence us) where nobody remembered how anything was done
- csande17 4y ago
  I have done iPhone development, and I can say with confidence that it is less work to take an iOS 17 app and update it to iOS 18 than it is to take nothing and create an iOS 18 app from scratch. You still need a non-zero number of people who know how the iOS app works, but the number you need is smaller.
SNosTrAnDbLe 4y ago
As long as you have good product requirements, creation is actually very simple. You have freedom to choose the technology and the tools. However, The moment that you discover that your AWS bill exceeds your engineering budget, you will have a different view of maintenance. People will now start calling it resilience, scale, optimization, etc. And then one day, the db will need to be partitioned (almost always, if the product is successful) and then the people who created the mess [almost always using a nosql database as it was available ]will run for the exits. You (or the poor unthanked ‘maintenance’ engineer ) will start learning about why distributed systems are hard to maintain.
lazide 4y ago
Oh, they realize it - which is why the managers and execs whose ongoing career trajectories require managing larger and larger orgs spend so much time coming up with more work! Most line engineers often realize it too pretty quickly, which is why we end up with so many new frameworks every time there is a huge boom cycle.

hotpotamus 4y ago

Fairly recently I moved from a company of about 8,000 to a company of 54 or so. At first I wondered how the tiny company got anything done, but they've been around for 30 years so I figured they must have some skill. Now I wonder what the hell all those 8,000 people actually did. Each team you just named is 1-2 people at the current gig.

bogota 4y ago
That really doesn’t say anything. Those teams all do very different thinks depending on the problem space. You’re not really making an argument though you are just stating two situations and hoping people arrive at your conclusion of big company is stupid.
- hotpotamus 4y ago
  I think anyone who has interacted with a big organization (company, government, religion, etc...) comes to the conclusion that they're disfunctional in some way. I agree that it doesn't say much, but I do wonder, how many engineers built the original Uber app and how many does the company employee today? I'm betting it's more, and I wonder how much additional functionality they've added over the years.
MonkeyMalarky 4y ago
I work a startup with less than 15 technical employees and have experience at tech companies ranging from 100s to 100s of thousands of employees. Suggesting that one could accomplish or maintain a platform like uber with so few heads is a farce.
- pclmulqdq 4y ago
  A team of 15 probably couldn't. A team of 50-100 probably could maintain something of similar complexity to the core uber app. Copycats exist using many fewer resources.
  - menzoic 4y ago

alkonaut 4y ago

These aren’t unique apps though. In my deregulated taxi market all taxi companies (dozens) have Uber functionality where you track cars on maps, pay via app, book rides in the app and so on. And many of the largest ones use the same app. Because they aren’t in that business, they are in the taxi business. If there is a margin to be found in scheduling or pricing, then their app supplier should provide it. This is perhaps what Uber should be doing: making the white label apps for local companies doing ride services. Not sure how many taxi markets are that unregulated that they allow it.