16 ms·

I often hear this logic from inexperienced engineers. My answer to them is: Then why don't you do it? <grin> Recently a junior engineer said this to me about

by malux85 10y ago

I often hear this logic from inexperienced engineers. My answer to them is: Then why don't you do it? <grin> Recently a junior engineer said this to me about Uber, and I helped him to understand - His logic was "it's just a taxi app". There were loads of Taxi apps before Uber and loads of them after Uber. Yet none of them were uber? Sure that a medium complexity CRUD app can do the pickup and scheduling, and spit out some json to the app. But what if you have 100,000 journeys taking place simultaneously, and you must track their positions so that you can render the journey map on the invoice? Can you do live traffic planning and re-route around the busy traffic on the fly? Does your weekend include the full billing system? This is a mandatory requirement for a business. Can you spot busy periods and increase the fares according to the laws of supply and demand? All online in realtime? Can you continuously A/B test this to optimise profits? Can you deal with the fact that maps and roads are always changing? All of these and more are the things that make Uber, Uber, otherwise you're just one of those shitty taxi apps that failed. Still think you can build it in a weekend?

dagw 10y ago
And even that is only a small part of what makes Uber, Uber. If you want to actually compete with Uber, then once you've gotten all those minor details worked out, you're going to have to tackle the real problem which is dealing with 100's of different regulatory frameworks for offering taxi services, being a taxi driver (or a not-taxi driver as the case may be), hiring of private contractors and two dozen or so other entirely non-technical things neither you nor I have considered.
- nilved 10y ago
  That's what the problem is. You can invent something in a weekend; the red tape takes longer. I think that still counts as "built in a weekend."
  - pixl97 10y ago
    Your comment makes no sense. Invent is a pretty meaningless word in this case. Invent doesn't mean 'make a product capable in working in the real world where it has to follow laws, physical limitations, and deal with stupid people'. If you invent an app in a few hours, then get fined out of existence your app sucks. If you invent an app in a few hours, then it crashes under high load, your app sucks. If you invent an app in a few hours and your code sucks and you can't adapt it later, your app sucks.
    - nilved 10y ago
      > If you invent an app in a few hours, then it crashes under high load, your app sucks. Yes > If you invent an app in a few hours, then get fined out of existence your app sucks. No
      - dpark 10y ago
        Apps that stop working because the company folds definitely suck.
      - pixl97 10y ago
        >> If you invent an app in a few hours, then get fined out of existence your app sucks. >No Sorry, but back here in reality apps must comply to regulations. It's your job as a voter to make sure your regulations comply with reality.
        nilved 10y ago
        For one, not everyone cares about the rules. For two, rules rarely apply to all people all the time. For three, this is external to the apps and you can hardly judge the app for what arbitrary regulations their location has at that time.
        kelnos 10y ago
        Caring or not caring about the rules is irrelevant if those rules make it impossible for you to operate. Uber has famously skirted rules and has gotten away with it largely because they've been able to throw VC money at PR, lobbying, and paying fines. Unless you happen to be similarly lucky funding-wise, your first round or two of fines for breaking rules can easily shut you down permanently. Maybe it's a bit hyperbolic to say that this would mean "your app sucks", but the end result is that you built something that no one can use and you can't make money of of. That sucks.
- mamon 10y ago
  >> dealing with 100's of different regulatory frameworks Isn't ignoring regulations the most often quoted reason for Uber's success?
  - hockley 10y ago
    Having an effective strategy to skirt regulations probably requires just as much knowledge of the regs as a company who complies with them.
    - Frondo 10y ago
      I don't think that's really true in this case. In the few cities I know any details for, the Uber answer was, "we'll just do it until the city sues us". That doesn't really take any special knowledge, just preparedness with the lawyers.
    - dragonwriter 10y ago
      > Having an effective strategy to skirt regulations probably requires just as much knowledge of the regs as a company who complies with them. Not really. The "effective strategy to skirt regulations" seems to be "when someone makes an issue out of it, we'll burn investor money on PR and lobbying against the regulations, and on paying any penalties that get assessed for violations". For that, you don't need much advance study of the regulations, just a deep supply of investor funds.
  - deleted 10y ago
    [deleted]
  - BurningFrog 10y ago
    Ignoring regulations is easy. Getting regulations to ignore you is the hard part.
  - scythe 10y ago
    They don't "ignore" regulations. They violate regulations. They do so strategically or they would have been shut down long ago. For example, if public opinion weren't on their side, perhaps due to, say, Uber rides being as dangerous as they're sometimes claimed to be rather than as safe as statistics show them to be, some of those "little" city lawsuits could have blown up much worse.
- dbbk 10y ago
  Something I find really interesting is that Uber drivers in the US are ordinary people. In the UK, they are straight up taxi drivers. It's the same brand for two totally different implementations of the idea.
amelius 10y ago
Well, with 2000 engineers I could do it in a weekend :) Anyway, here's a related link: https://www.quora.com/Why-do-AirBnb-and-Uber-need-so-many-engineers https://www.quora.com/Why-do-AirBnb-and-Uber-need-so-many-en... And here another: https://news.ycombinator.com/item?id=12597232 https://news.ycombinator.com/item?id=12597232
- betimsl 10y ago
  You couldn't. No way you can delegate work to 2k engineers and tell them what to do for next 2 days. Physically impossible.
  - amelius 10y ago
    Yes, Amdahl's law. I'd probably just use the 10 most productive engineers, and tell the others to prepare for testing :)
    - betimsl 10y ago
      I don't want to sound bad, but again you couldn't do it. Say you have 2k engineers for next two days. Where do you begin?
      - davidy123 10y ago
        Describe the app generally, and leave it to them to form their own teams and solutions. Hackthon style, and hackathons at least usually have functional prototypes by their end.
      - triplesec 10y ago
        You are correct, but are taking these guys too seriously. They know about the mythical man month and are just riffing, for better or worse.
  - philbarr 10y ago
    Not my problem - I'm their manager. If I have 2000 engineers I just make one of them Lead Dev and then shout at him when he hasn't been able to deliver after I gave him 1999 software engineers. What an idiot.
atomical 10y ago
Also, it's often the case that it's better to buy a tool and integrate it into the company than build from scratch. It's especially true with a small team. It's not the most romantic idea and sometimes engineers feel that they could build the solution themselves in a weekend.
esrauch 10y ago
I'm pretty sure uber doesn't do any of that locations or traffic routing stuff you mentioned. When I take uber the driver just has their favorite app if Waze, Google or Apple Maps for the actual routing or directions.
- madeofpalk 10y ago
  It has to for the time estimates and finding the 'closest' driver to you.
  - ErikDub 10y ago
    For me the time estimates are always super incorrect and seem only based on the distance.
    - TheDrizzle43 10y ago
      I use to live next to a highway with the closets exit being a few miles away and I would constantly get drivers on the highway as my closest driver. I always had to cancel since they were actually ~15 minutes away, not 3-5.
    - sfifs 10y ago
      I have found that Uber's estimates get better with time. When Uber was newer in my city, it used to give ridiculous underestimates. They've become far more realistic now.
- cwilkes 10y ago
  Or the passenger in the case of Uber Pool. I couldn't believe what Uber expected of a driver when a new Pool request came up. They had to hit a button, look at the screen, rethink how they were going to go somewhere. Oh and then worry if the requester will cancel. That happened on my last trip. I felt bad for the driver so I helped him out finding the best way to pick up a passenger after the first two cancelled. I think Pool is a good thing but not in rush hour traffic where going slightly off the route adds 10 minutes to a trip minimum.
AlexandrB 10y ago
I'm pretty sure Uber uses Google Maps in for a lot of it's mapping and navigation [1]. I'm not saying Uber adds no value - payment processing isn't easy, but it's not solving any new mapping problems that Google hasn't already solved. Its main innovation has been to ignore existing taxi laws by classifying itself as "ride-sharing". [1] http://www.zdnet.com/article/uber-to-invest-500m-in-mapping-project-to-skirt-google-maps-report/ http://www.zdnet.com/article/uber-to-invest-500m-in-mapping-...
- hackerboos 10y ago
  I doubt Uber would have gotten started without leaning on Google for both mapping and directions. This benefited them both as Google incorporated Uber back into it's Maps product.
- the_watcher 10y ago
  Uber initially (and still does) rely Google Maps for a lot, but they have an internal team working on their own mapping, and have spent a lot of money acquiring map-related tech.
  - philjohn 10y ago
    Now. But they initially bootstrapped it with Google Maps, which was sensible to do for their initial MVP, which is all an "I could do that in a weekend" project is.
- Pyxl101 10y ago
  Can you provide a source for the claim that Uber violates taxi laws? As far as I'm aware, Uber doesn't violate taxi laws. Uber started out providing "black car" services which are not classified or regulated as taxis. Never have been, still aren't. Black car services are ones where you schedule a trip in advance, and there's no "hailing on the street". Being able to hail taxis is what makes them taxis and subject to regulation. A lot of the drivers who first began working for Uber were existing black car drivers, and who operated their own black car business on the side. Many still do. Uber didn't come along and make this existing class of ride service illegal. The only vehicles subject to taxi regulation are ones that offer rides to people on the street without prior arrangement, as far as I'm aware.
rfrey 10y ago
I agree with everything you say, but that response, like the junior engineer, focusses on the technology. So give people six months not a weekend -- there's a good chance they still won't be Uber. The success of many companies, and probably all of the unicorns, has nothing to do with technology. The tech is necessary, of course, but so are desks and an accounting department. Internalizing that has been difficult for me as an engineer.
- malux85 10y ago
  I know - but I was talking to a junior engineer, and I was concentrating on the technical aspects to inspire him. I expected him to go off and actually attempt building it, that way he would get some more experience. And he did! He went off that weekend and wrote a proof of concept route planner, it was great to see him learn something new and complex
  - Shivetya 10y ago
    many a junior engineer who persist on the idea its easy, can be done quicker, cheaper, and such, also rarely have the needed dedication to see it through especially when it takes longer than expected, missing requirements are identified, and such. I have seen multi million dollar projects hit the same snags, horribly under scoped all because Mr Easy didn't think about asking all of was needed. They saw the tree and missed the forest
    - paulmd 10y ago
      Proper project scoping (or to rephrase: identifying the true core business needs) is truly one of the hardest problems in tech. Over-scoping makes you end up with a ponderous system that doesn't serve core business needs very well, while underscoping can lock you into poor initial decisions that cripple your ability to expand into other related functionality. What's the expression? "Plan your system for 100x growth, but build your system for 10x growth". Something like that except for functionality rather than scalability. That and supporting the system. Junior engineers tend to think about building the tech, which is honestly the easy part. Keeping it working until the last of your customers are finally ready to upgrade 10 years later is harder than junior engineers tend to think.
erjjones 10y ago
After several startup failures, the number one lesson I have learned is that you better have the right team who can execute. Uber has the right team http://www.businessinsider.com/the-power-players-of-uber-2016-1 http://www.businessinsider.com/the-power-players-of-uber-201...
wellpast 10y ago
To me the question isn't "Think you can build it in a weekend?" You mentioned 5 product "concerns" that Uber must contend with to make a point. No doubt if we brainstormed more we could come up with perhaps 10 or 20 more such "concerns". Now let's be very generous and assign 10 engineers to each concern. I still come up with a maximum of 200 engineers for Uber. But Uber has 2000 engineers. I don't see any creative ideating that would justify that many engineers _as necessary for the top or bottom line operation of Uber_. They are there for other reasons but not because Uber needs that many engineers to operate.
- thisisit 10y ago
  To repeat myself from an earlier comment. How does one even arrive at the number 200 based on the complexity of the problem? Secondly not all 2000 will be working on their core app. There will be solutions required at each level. For example in some countries cab services are provided by larger contractors employing drivers and not individual drivers themselves. So Uber needs to have a billing system which collates data from their individual drivers and then calculates the payout to the company. This requires a separate set of engineers, not working on the core app. And then there are HR systems, Finance Systems, every bit they are not contracting to an Indian Service company has to be handled by an "engineer".
  - wellpast 10y ago
    Okay. Then how many engineers would Uber need to have for you to say "that's too many"?
    - thisisit 10y ago
      I don't really know. What I do know is people seem to misunderstand engineering team size as a simple sum of people working on the Uber app. It is not only the android/ios developer or the full stack developer who is an engineer in Uber. An IT administrator who helps people, technical or non-technical, with their work laptops also qualifies as an engineering team staff to the outside world.
    - 10y ago
usgroup 10y ago
I think the critic has the benefit of hindsight which may translate to 1000s or hours saved in DEV. E.g. Copying Uber verbatim versus all the experimentation to get there. Hence it's not uncommon to see clones of things (e.g. Dropbox, slack, etc) developed at fractional cost. Your junior may be onto something , get shares in his. Ew startup quick !
novaleaf 10y ago
I was offered to interview at a company, they wanted me to do a coding "pre-screening" which consisted of creating a full-stack, and fully operational registration website from scratch. Maybe I'm a super slow architect and developer, but I'd estimate that to be a greater than 8 hour time commitment. I assume that the org's leadership acted in good faith, that someone honestly think's a non-slapdash solution would be a couple hours of work. It boggles my mind. And yes, I declined their invitation to pre-screen and thus did not complete the interview process.
- NhanH 10y ago
  Just to confirm, you meant just register -> store to database + forgot password and validation right? (Greater than 8 hour time commitment do sound about right, but I'm just curious to make sure I read it correctly).
  - novaleaf 10y ago
    The instructions did not give an upper bound in terms of functional requirements, though the lower bound of "realistic use" was given! So yes, I would assume that includes things like full email validation round-trip too. Even just slopping together an in-memory, no-email-sent deployed solution is at least 3 or 4 hours in my book, which seems way excessive for a pre-screening question!
    - oswamano 10y ago
      And you had to do that from scratch? No libraries allowed? That does seem rough. With libraries allowed you could probably spin something up with rails + scaffolding + devise though.
      - deleted 10y ago
        [deleted]
      - novaleaf 10y ago
        maybe libraries are allowed, but I don't know any that can really turn this into a 30 minute project. And even researching libraries is hours of work :) If you have any suggestions for this on nodejs, I'll be happy to add it to my interviewing toolbelt :D
madeofpalk 10y ago
"If you guys were the inventors of Facebook, you'd have invented Facebook." The Social Network.
emilsedgh 10y ago
Fully agreed. However, remember l that Uber (probably) started without any of those complexities. Probably just on a weekend. So I think the absolutely incorrect "I can build this in a weekend" could be rephrased as "An absolute MVP (Or a proof of concept) like this product could be built in a weekend". This would make sense, right?
- kafkaesq 10y ago
  "An absolute MVP (Or a proof of concept) like this product could be built in a weekend". Maybe, theoretically, in some cases. But even so that's very different from the original "I could build that..." bloviation.
forgetsusername 10y ago
>Yet none of them were uber? You underestimate the amount of luck involved in becoming Uber. It's not all luck, but luck is a major factor.
- vidarh 10y ago
  Consider this then: If you could build an app as polished as Uber's, there are hundreds of minicab companies in the UK alone, most of which have apps massively inferior to Uber yet has to compete with them, and that are thus a market for better apps. There probably is a lot of luck involved in becoming Uber, but if you can make an app that good in a short amount of time, then the opportunity cost in doing that and sending a demo round to a few dozen minicab companies is very, very low. Yet these companies are still stuck with horrible apps, because in reality it takes a lot of time to develop a good one, even if a prototype is fairly trivial.
fail2fail2ban 10y ago
Data federation is the key to complex data. In a month or two, the first cut anyway, I doubt it could be done in a week-end.
WayneBro 10y ago
Uber didn't start with all of that either. The MVP can be built in a weekend though.
- mianos 10y ago
  Nope, that is the point.
kenjackson 10y ago
And then you have to get a million people to say, "I'm just going to Uber there." Except replace Uber with the name of your new app.
20years 10y ago
The hardest parts of starting and running a business generally have nothing to do with tech. That is even true for most software businesses. This is what most developers who have not started or ran a business don't truly understand.
VOYD 10y ago
Oh yeah, infrastructure & marketing ;)
andrei_says_ 10y ago
Also, all the edge cases which become visible only after real users start pounding the service exposing all "this should never happen" conditions.
taco_emoji 10y ago
> Can you spot busy periods and increase the fares according to the laws of supply and demand? And beyond the technical issues: Can you effectively deal with the negative PR that results when you increase fares during a natural disaster or terrorist attack? Uber isn't just an app, it's also a company and a brand and a service. It's something people understand, it's something that's popular, it's something that people rely on. So sure, let's say a really good dev could crank out a software engine that does everything Uber does in a month. Now what?
- jcoffland 10y ago
  You seem to be implying that really good devs are just lying around not being used whereas great PR guys and execs are the real value. I don't buy it.
  - cmdrfred 10y ago
    The evidence of PR being effective is right there if you think about it.
    - jcoffland 10y ago
      The evidence of good tech being important is at your finger tips.
  - taco_emoji 10y ago
    I'm not really sure how you got that from the words I wrote. There's tons of work in addition to the tech which leads to a success story like Uber. That doesn't imply that the tech doesn't matter, just that other stuff does also.
mgalka 10y ago
While I agree 100%, I think the answer is more satisfying when viewed a different perspective. It's not that Uber needs all those engineers. It's just a question of marginal cost vs marginal return. Uber made 1.5 billion in revenue in 2015. An engineer costs roughly $150k / yr. An additional 100 engineers only have to make enough small improvements to increase revenue by 1% to pay for themselves.
- acchow 10y ago
  > An engineer costs roughly $150k / yr This number is far too low. Uber is headquartered in San Francisco.
inputcoffee 10y ago
A lot of the work is convincing people: 1. Convince customers to download the app, give their credit card, and then trust their rides and selves to a driver 2. Convince drivers to clean up their cars, download the driver app, and turn it on, and wait for customers to ask them for rides
deleted 10y ago
[deleted]
hinkley 10y ago
As an inexperienced engineer I did the same thing. My punishment for my hubris was to have bizdevs who felt the same way about us. The weird thing is though, I still actively encourage new devs to make this mistake in certain circumstances. For one thing, telling them no isn't going to help, we have no shared context, and the math of their productivity versus mine works against me spending too much time convincing them. If the problem has a logistical or bureaucratic component, once in a while the stars align and they manage to pull off something the department has been trying to do for years but always runs into a wall. Some people in an organization will assume something is true if they hear it from enough independent parties. I know if three people ask me the same question about a block of our code, I start looking at that code suspiciously. Clearly something is wrong with it. Sending the 5th guy to ask some IT guy or product manager he same question, especially in the way a new person tends to formulate questions, sometimes knocks the cobwebs off and the person decides to change their behavior or volunteer to do something they have resisted doing before. A week of junior dev time for a 5% chance to clear out a bag of tech debt is a good investment IMO. And if it doesn't work they learn something about why things are the way they are. I had a senior coworker who used to laugh and say "You're new here aren't you?" and I started giving him grief for doing it. Sometimes the new guy is the only one who can get things changed.
- dancek 10y ago
  Great insight there. Additionally, the new guy will be much happier when he's treated the way you suggest. I know I would have appreciated that instead of the bs I got at my first proper job in the beginning.
- bonniemuffin 10y ago
  I always try to point out to the junior folks when a thing is janky and broken for "historical" reasons rather than technical reasons, in the hope that their fresh eyes on the problem will find a better solution. Sometimes we're still just coasting on the best solution we could come up with 2 years ago, and in those cases it's likely that we could do better if we re-think the problem from scratch.
wslh 10y ago
I think you can ask a simpler question: how do you get traction, drivers and passengers included? You application will be invisible, nobody will see it.
sbov 10y ago
And my answer to your question is: your reply is pretty far off base. Quite simply: when Uber first launch, Uber was not the Uber you are describing. Telling an engineer they need all these things from the start is completely wrong. Yes, competing with Uber now, with "this can be done in a weekend", is naive. But that's not the point. The point is, that there are plenty of problems you can make a lot of money on, with a timeline anywhere from a week to a year. Some will be sustainable, and some will be simple cash grabs. The hardest part is identifying not just what, but when. If you have enough connections in the industry, it can be much easier to predict this than if you are on the outside of things. I have built plenty of things people would say "I could do it in a weekend". And yes, a weekend is a little short, but many of them took just a week, at least initially. The answer is not "Uber does all these things, you need to too." The answer is, "you need to predict the next Uber, so you don't have to do all the things Uber currently does."
sumitgt 10y ago
ALso, they are literally trying to solve a problem similar to the travelling salesman problem when you consider Uber Pool scheduling, Uber Eats, etc.
- pjlegato 10y ago
  True, but they don't have to find the optimal solution, or even anything close to it. They just have to find a solution that's slightly better than the next-best solution, which in most cases is very far from optimal.
carc 10y ago
I think a related thing people say (that makes me cringe) is that xyz is "just a CRUD app", quite dismissively. You could argue that the vast majority of applications are "just CRUD apps"! Once you get up to a certain scale, even "basic CRUD apps" are complicated.
spynxic 10y ago
Thanks for the nice specifications!
downandout 10y ago
You couldn't build the Uber of today without significant resources, however you could indeed build the version of Uber that made them popular and got them access to those resources in a weekend. Uber started out as a black car app. They got lucky, went viral, and the founders were well connected enough to get funding to build out much of the advanced functionality you're referring to after the app already became popular. It isn't the advanced functionality and scalability you're talking about here (that was built in reaction to its popularity) that made it popular. It was their MVP.
InclinedPlane 10y ago
Even more than that: code is only a tiny part of a tech business, even one that has code as its most critical foundation. A classic example is banking or money transfers (like paypal). So many people think that financial services are nothing more than moving bits around, which seems like an easy thing to code. Aside from the fact that it's not as easy to code as one might imagine, that part is maybe only 1-5% of the business. Paypal got where they are not because of the quality of their code or their operations but because of their relationships. They established relationships with banks, with regulatory agencies, with governments, and they spent years and years doing these things. They signed contracts, they established trust, they created systems for interfacing with many different banks and governments (not just tech systems, but policies and personnel). The result is that paypal is now one of the easiest ways to move money around the world with minimal friction. Cloning paypal's tech wouldn't enable you to clone their success, for those reasons. Same thing with Amazon. Amazon's user facing software is only a fraction of their operations, their main competitive advantages are selection, price, fast fulfillment, and customer service.
developer2 10y ago
You're going to talk about Uber? Watch this video: [1]. He talks about every regret regarding their infrastructure. At first you kind of nod your head along with "yeah, it's not that easy", but as he keeps talking you can't help but wonder why the company has absolutely no internal technical direction whatsoever. They employ over 2000 engineers (just devs, excluding support staff, etc.). They use micro-services designed to the point where teams can't reuse pre-existing services. They are rewriting the same functionality over and over, and over and over again, as separate teams don't even have a clue what has already been written. Pick a piece of functionality you need. There are straight up 20 different APIs that do the exact same thing, but good luck figuring out which one you should be using - oh wait, why bother when you can just write the 21st version of the same thing. They are at the point where they have no clue what their repositories contain. In the video, he can't even provide an accurate number of deployed micro-services. THEY CANNOT EVEN ASSESS WHAT THEY ARE RUNNING IN PRODUCTION. They're literally drowning, and cannot recover. The point of the article is wrong. It's not about what can be done in one weekend, it's what can be done in 12-24 months by a competent team. Yes, Uber operates internationally which comes with a very crazy set of challenges. 2000 engineers worth of challenge? Not even remotely close. You should need fewer than 100 people who really know what they're doing, and another 300-400 people who can follow the lead of the first 100. If you need more than that for a single product (ie: Google does not apply as they have 100+ full products), you are doing things wrong. If you're going to provide the anti-thesis, don't use Uber as your example. They don't even understand how their business is managing to remain afloat from a technical perspective. [1] https://www.youtube.com/watch?v=kb-m2fasdDY https://www.youtube.com/watch?v=kb-m2fasdDY
- throwawayuber 10y ago
  > They use micro-services designed to the point where teams can't reuse pre-existing services. They are rewriting the same functionality over and over, and over and over again, as separate teams don't even have a clue what has already been written. That's quite an exaggeration. Sure, there is duplication, because Uber has chosen one side of the trade off (duplication) as better than the other (coordination, blocking). I can tell you we don't have 21 versions of the same thing. By the way, what are the chances of building a 500+ person team without hiring a few duds? With such a large team you'd expect a regression toward the mean. Uber only has one product? - UberX - Pool - Commute - Hop - Rush - Eats - Taxi Each of those products is customized in the city or region that it operates in. For example, airports are FIFO queues [1]. At certain airports (e.g. SFO) you can choose from pre-filled destinations like "Departures Level 2, Door 10". Forward dispatch preemptively matches drivers to their next client to minimize downtime [2]. Riders who are late to the pickup get charged on a time basis [3]. You can schedule rides in advance [4]. Sure, a dedicated team could replicate some of these features, but those are just the features that launched. There are TONS of features that launch in only one city, or only to a subset of drivers, or whatever. Which is more likely? That every tech company like Twitter, Square, Slack, Uber, Lyft, AirBNB, Dropbox, Github, Instacart, Stripe (all "one product" companies) are mismanaged or that you don't understand the complexity of running an actual large growing business? [1]: https://newsroom.uber.com/australia/first-in-first-out-airport-queues/ https://newsroom.uber.com/australia/first-in-first-out-airpo... [2]: https://newsroom.uber.com/sri-lanka/forwarddispatch/ https://newsroom.uber.com/sri-lanka/forwarddispatch/ [3]: https://www.yahoo.com/tech/uber-hit-penalty-ride-3-minutes-200241386.html https://www.yahoo.com/tech/uber-hit-penalty-ride-3-minutes-2... [4]: https://www.uber.com/info/scheduled-rides/ https://www.uber.com/info/scheduled-rides/
aagha 10y ago
And on top of all of that, can you get 100K people to use your app?!
imagist 10y ago
I think you're making a related mistake, which is to overestimate the importance of the tech to the business. When Uber first released, my guess is they probably couldn't do most of what you list above. But it didn't matter, because they had one compelling feature: they routed around regulation. This allowed them to pay drivers more and charge riders less than traditional taxis, while taking a cut for themselves. This is a clearly profitable position to be in, which means that they have the money to bring in capable business analysts and programmers, and the rest of what you say above will happen naturally. The taxi apps before Uber didn't recognize that the killer feature was routing around regulation, and the taxi apps after that didn't do it first. Sure, I can't write Uber in its current state in a weekend, but I could absolutely write Uber's minimum viable product in a few days. The problem is having the right combination of a good idea, the correct understanding of why it's a good idea, and the expertise to execute it (not just technical expertise).
rimantas 10y ago
I think you chose a bad example. Imho Uber has waaay to many engineers for what they are doing: to the point where they need to invent work for themselves with no business value.

by malux85 10y ago

dagw 10y ago

And even that is only a small part of what makes Uber, Uber. If you want to actually compete with Uber, then once you've gotten all those minor details worked out, you're going to have to tackle the real problem which is dealing with 100's of different regulatory frameworks for offering taxi services, being a taxi driver (or a not-taxi driver as the case may be), hiring of private contractors and two dozen or so other entirely non-technical things neither you nor I have considered.

nilved 10y ago
That's what the problem is. You can invent something in a weekend; the red tape takes longer. I think that still counts as "built in a weekend."
- pixl97 10y ago
  Your comment makes no sense. Invent is a pretty meaningless word in this case. Invent doesn't mean 'make a product capable in working in the real world where it has to follow laws, physical limitations, and deal with stupid people'. If you invent an app in a few hours, then get fined out of existence your app sucks. If you invent an app in a few hours, then it crashes under high load, your app sucks. If you invent an app in a few hours and your code sucks and you can't adapt it later, your app sucks.
  - nilved 10y ago
    > If you invent an app in a few hours, then it crashes under high load, your app sucks. Yes > If you invent an app in a few hours, then get fined out of existence your app sucks. No
    - dpark 10y ago
      Apps that stop working because the company folds definitely suck.
    - pixl97 10y ago
      >> If you invent an app in a few hours, then get fined out of existence your app sucks. >No Sorry, but back here in reality apps must comply to regulations. It's your job as a voter to make sure your regulations comply with reality.
      - nilved 10y ago
        For one, not everyone cares about the rules. For two, rules rarely apply to all people all the time. For three, this is external to the apps and you can hardly judge the app for what arbitrary regulations their location has at that time.
        kelnos 10y ago
        Caring or not caring about the rules is irrelevant if those rules make it impossible for you to operate. Uber has famously skirted rules and has gotten away with it largely because they've been able to throw VC money at PR, lobbying, and paying fines. Unless you happen to be similarly lucky funding-wise, your first round or two of fines for breaking rules can easily shut you down permanently. Maybe it's a bit hyperbolic to say that this would mean "your app sucks", but the end result is that you built something that no one can use and you can't make money of of. That sucks.
mamon 10y ago
>> dealing with 100's of different regulatory frameworks Isn't ignoring regulations the most often quoted reason for Uber's success?
- hockley 10y ago
  Having an effective strategy to skirt regulations probably requires just as much knowledge of the regs as a company who complies with them.
  - Frondo 10y ago
    I don't think that's really true in this case. In the few cities I know any details for, the Uber answer was, "we'll just do it until the city sues us". That doesn't really take any special knowledge, just preparedness with the lawyers.
  - dragonwriter 10y ago
    > Having an effective strategy to skirt regulations probably requires just as much knowledge of the regs as a company who complies with them. Not really. The "effective strategy to skirt regulations" seems to be "when someone makes an issue out of it, we'll burn investor money on PR and lobbying against the regulations, and on paying any penalties that get assessed for violations". For that, you don't need much advance study of the regulations, just a deep supply of investor funds.
- deleted 10y ago
  [deleted]
- BurningFrog 10y ago
  Ignoring regulations is easy. Getting regulations to ignore you is the hard part.
- scythe 10y ago
  They don't "ignore" regulations. They violate regulations. They do so strategically or they would have been shut down long ago. For example, if public opinion weren't on their side, perhaps due to, say, Uber rides being as dangerous as they're sometimes claimed to be rather than as safe as statistics show them to be, some of those "little" city lawsuits could have blown up much worse.
dbbk 10y ago
Something I find really interesting is that Uber drivers in the US are ordinary people. In the UK, they are straight up taxi drivers. It's the same brand for two totally different implementations of the idea.

amelius 10y ago

Well, with 2000 engineers I could do it in a weekend :) Anyway, here's a related link: https://www.quora.com/Why-do-AirBnb-and-Uber-need-so-many-engineers https://www.quora.com/Why-do-AirBnb-and-Uber-need-so-many-en... And here another: https://news.ycombinator.com/item?id=12597232 https://news.ycombinator.com/item?id=12597232

betimsl 10y ago
You couldn't. No way you can delegate work to 2k engineers and tell them what to do for next 2 days. Physically impossible.
- amelius 10y ago
  Yes, Amdahl's law. I'd probably just use the 10 most productive engineers, and tell the others to prepare for testing :)
  - betimsl 10y ago
    I don't want to sound bad, but again you couldn't do it. Say you have 2k engineers for next two days. Where do you begin?
    - davidy123 10y ago
      Describe the app generally, and leave it to them to form their own teams and solutions. Hackthon style, and hackathons at least usually have functional prototypes by their end.
    - triplesec 10y ago
      You are correct, but are taking these guys too seriously. They know about the mythical man month and are just riffing, for better or worse.
- philbarr 10y ago
  Not my problem - I'm their manager. If I have 2000 engineers I just make one of them Lead Dev and then shout at him when he hasn't been able to deliver after I gave him 1999 software engineers. What an idiot.

atomical 10y ago

Also, it's often the case that it's better to buy a tool and integrate it into the company than build from scratch. It's especially true with a small team. It's not the most romantic idea and sometimes engineers feel that they could build the solution themselves in a weekend.

esrauch 10y ago

I'm pretty sure uber doesn't do any of that locations or traffic routing stuff you mentioned. When I take uber the driver just has their favorite app if Waze, Google or Apple Maps for the actual routing or directions.

madeofpalk 10y ago
It has to for the time estimates and finding the 'closest' driver to you.
- ErikDub 10y ago
  For me the time estimates are always super incorrect and seem only based on the distance.
  - TheDrizzle43 10y ago
    I use to live next to a highway with the closets exit being a few miles away and I would constantly get drivers on the highway as my closest driver. I always had to cancel since they were actually ~15 minutes away, not 3-5.
  - sfifs 10y ago
    I have found that Uber's estimates get better with time. When Uber was newer in my city, it used to give ridiculous underestimates. They've become far more realistic now.
cwilkes 10y ago
Or the passenger in the case of Uber Pool. I couldn't believe what Uber expected of a driver when a new Pool request came up. They had to hit a button, look at the screen, rethink how they were going to go somewhere. Oh and then worry if the requester will cancel. That happened on my last trip. I felt bad for the driver so I helped him out finding the best way to pick up a passenger after the first two cancelled. I think Pool is a good thing but not in rush hour traffic where going slightly off the route adds 10 minutes to a trip minimum.

AlexandrB 10y ago

I'm pretty sure Uber uses Google Maps in for a lot of it's mapping and navigation [1]. I'm not saying Uber adds no value - payment processing isn't easy, but it's not solving any new mapping problems that Google hasn't already solved. Its main innovation has been to ignore existing taxi laws by classifying itself as "ride-sharing". [1] http://www.zdnet.com/article/uber-to-invest-500m-in-mapping-project-to-skirt-google-maps-report/ http://www.zdnet.com/article/uber-to-invest-500m-in-mapping-...

hackerboos 10y ago
I doubt Uber would have gotten started without leaning on Google for both mapping and directions. This benefited them both as Google incorporated Uber back into it's Maps product.
the_watcher 10y ago
Uber initially (and still does) rely Google Maps for a lot, but they have an internal team working on their own mapping, and have spent a lot of money acquiring map-related tech.
- philjohn 10y ago
  Now. But they initially bootstrapped it with Google Maps, which was sensible to do for their initial MVP, which is all an "I could do that in a weekend" project is.
Pyxl101 10y ago
Can you provide a source for the claim that Uber violates taxi laws? As far as I'm aware, Uber doesn't violate taxi laws. Uber started out providing "black car" services which are not classified or regulated as taxis. Never have been, still aren't. Black car services are ones where you schedule a trip in advance, and there's no "hailing on the street". Being able to hail taxis is what makes them taxis and subject to regulation. A lot of the drivers who first began working for Uber were existing black car drivers, and who operated their own black car business on the side. Many still do. Uber didn't come along and make this existing class of ride service illegal. The only vehicles subject to taxi regulation are ones that offer rides to people on the street without prior arrangement, as far as I'm aware.

rfrey 10y ago

I agree with everything you say, but that response, like the junior engineer, focusses on the technology. So give people six months not a weekend -- there's a good chance they still won't be Uber. The success of many companies, and probably all of the unicorns, has nothing to do with technology. The tech is necessary, of course, but so are desks and an accounting department. Internalizing that has been difficult for me as an engineer.

malux85 10y ago
I know - but I was talking to a junior engineer, and I was concentrating on the technical aspects to inspire him. I expected him to go off and actually attempt building it, that way he would get some more experience. And he did! He went off that weekend and wrote a proof of concept route planner, it was great to see him learn something new and complex
- Shivetya 10y ago
  many a junior engineer who persist on the idea its easy, can be done quicker, cheaper, and such, also rarely have the needed dedication to see it through especially when it takes longer than expected, missing requirements are identified, and such. I have seen multi million dollar projects hit the same snags, horribly under scoped all because Mr Easy didn't think about asking all of was needed. They saw the tree and missed the forest
  - paulmd 10y ago
    Proper project scoping (or to rephrase: identifying the true core business needs) is truly one of the hardest problems in tech. Over-scoping makes you end up with a ponderous system that doesn't serve core business needs very well, while underscoping can lock you into poor initial decisions that cripple your ability to expand into other related functionality. What's the expression? "Plan your system for 100x growth, but build your system for 10x growth". Something like that except for functionality rather than scalability. That and supporting the system. Junior engineers tend to think about building the tech, which is honestly the easy part. Keeping it working until the last of your customers are finally ready to upgrade 10 years later is harder than junior engineers tend to think.

erjjones 10y ago

After several startup failures, the number one lesson I have learned is that you better have the right team who can execute. Uber has the right team http://www.businessinsider.com/the-power-players-of-uber-2016-1 http://www.businessinsider.com/the-power-players-of-uber-201...

wellpast 10y ago

To me the question isn't "Think you can build it in a weekend?" You mentioned 5 product "concerns" that Uber must contend with to make a point. No doubt if we brainstormed more we could come up with perhaps 10 or 20 more such "concerns". Now let's be very generous and assign 10 engineers to each concern. I still come up with a maximum of 200 engineers for Uber. But Uber has 2000 engineers. I don't see any creative ideating that would justify that many engineers _as necessary for the top or bottom line operation of Uber_. They are there for other reasons but not because Uber needs that many engineers to operate.

thisisit 10y ago
To repeat myself from an earlier comment. How does one even arrive at the number 200 based on the complexity of the problem? Secondly not all 2000 will be working on their core app. There will be solutions required at each level. For example in some countries cab services are provided by larger contractors employing drivers and not individual drivers themselves. So Uber needs to have a billing system which collates data from their individual drivers and then calculates the payout to the company. This requires a separate set of engineers, not working on the core app. And then there are HR systems, Finance Systems, every bit they are not contracting to an Indian Service company has to be handled by an "engineer".
- wellpast 10y ago
  Okay. Then how many engineers would Uber need to have for you to say "that's too many"?
  - thisisit 10y ago
    I don't really know. What I do know is people seem to misunderstand engineering team size as a simple sum of people working on the Uber app. It is not only the android/ios developer or the full stack developer who is an engineer in Uber. An IT administrator who helps people, technical or non-technical, with their work laptops also qualifies as an engineering team staff to the outside world.
  - 10y ago

usgroup 10y ago

I think the critic has the benefit of hindsight which may translate to 1000s or hours saved in DEV. E.g. Copying Uber verbatim versus all the experimentation to get there. Hence it's not uncommon to see clones of things (e.g. Dropbox, slack, etc) developed at fractional cost. Your junior may be onto something , get shares in his. Ew startup quick !

novaleaf 10y ago

I was offered to interview at a company, they wanted me to do a coding "pre-screening" which consisted of creating a full-stack, and fully operational registration website from scratch. Maybe I'm a super slow architect and developer, but I'd estimate that to be a greater than 8 hour time commitment. I assume that the org's leadership acted in good faith, that someone honestly think's a non-slapdash solution would be a couple hours of work. It boggles my mind. And yes, I declined their invitation to pre-screen and thus did not complete the interview process.

NhanH 10y ago
Just to confirm, you meant just register -> store to database + forgot password and validation right? (Greater than 8 hour time commitment do sound about right, but I'm just curious to make sure I read it correctly).
- novaleaf 10y ago
  The instructions did not give an upper bound in terms of functional requirements, though the lower bound of "realistic use" was given! So yes, I would assume that includes things like full email validation round-trip too. Even just slopping together an in-memory, no-email-sent deployed solution is at least 3 or 4 hours in my book, which seems way excessive for a pre-screening question!
  - oswamano 10y ago
    And you had to do that from scratch? No libraries allowed? That does seem rough. With libraries allowed you could probably spin something up with rails + scaffolding + devise though.
    - deleted 10y ago
      [deleted]
    - novaleaf 10y ago
      maybe libraries are allowed, but I don't know any that can really turn this into a 30 minute project. And even researching libraries is hours of work :) If you have any suggestions for this on nodejs, I'll be happy to add it to my interviewing toolbelt :D

madeofpalk 10y ago

"If you guys were the inventors of Facebook, you'd have invented Facebook." The Social Network.

emilsedgh 10y ago

Fully agreed. However, remember l that Uber (probably) started without any of those complexities. Probably just on a weekend. So I think the absolutely incorrect "I can build this in a weekend" could be rephrased as "An absolute MVP (Or a proof of concept) like this product could be built in a weekend". This would make sense, right?

kafkaesq 10y ago
"An absolute MVP (Or a proof of concept) like this product could be built in a weekend". Maybe, theoretically, in some cases. But even so that's very different from the original "I could build that..." bloviation.

forgetsusername 10y ago

>Yet none of them were uber? You underestimate the amount of luck involved in becoming Uber. It's not all luck, but luck is a major factor.

vidarh 10y ago
Consider this then: If you could build an app as polished as Uber's, there are hundreds of minicab companies in the UK alone, most of which have apps massively inferior to Uber yet has to compete with them, and that are thus a market for better apps. There probably is a lot of luck involved in becoming Uber, but if you can make an app that good in a short amount of time, then the opportunity cost in doing that and sending a demo round to a few dozen minicab companies is very, very low. Yet these companies are still stuck with horrible apps, because in reality it takes a lot of time to develop a good one, even if a prototype is fairly trivial.

fail2fail2ban 10y ago

Data federation is the key to complex data. In a month or two, the first cut anyway, I doubt it could be done in a week-end.

WayneBro 10y ago

Uber didn't start with all of that either. The MVP can be built in a weekend though.

mianos 10y ago
Nope, that is the point.

kenjackson 10y ago

And then you have to get a million people to say, "I'm just going to Uber there." Except replace Uber with the name of your new app.

20years 10y ago

The hardest parts of starting and running a business generally have nothing to do with tech. That is even true for most software businesses. This is what most developers who have not started or ran a business don't truly understand.

VOYD 10y ago

Oh yeah, infrastructure & marketing ;)

andrei_says_ 10y ago

Also, all the edge cases which become visible only after real users start pounding the service exposing all "this should never happen" conditions.

taco_emoji 10y ago

> Can you spot busy periods and increase the fares according to the laws of supply and demand? And beyond the technical issues: Can you effectively deal with the negative PR that results when you increase fares during a natural disaster or terrorist attack? Uber isn't just an app, it's also a company and a brand and a service. It's something people understand, it's something that's popular, it's something that people rely on. So sure, let's say a really good dev could crank out a software engine that does everything Uber does in a month. Now what?

jcoffland 10y ago
You seem to be implying that really good devs are just lying around not being used whereas great PR guys and execs are the real value. I don't buy it.
- cmdrfred 10y ago
  The evidence of PR being effective is right there if you think about it.
  - jcoffland 10y ago
    The evidence of good tech being important is at your finger tips.
- taco_emoji 10y ago
  I'm not really sure how you got that from the words I wrote. There's tons of work in addition to the tech which leads to a success story like Uber. That doesn't imply that the tech doesn't matter, just that other stuff does also.

mgalka 10y ago

While I agree 100%, I think the answer is more satisfying when viewed a different perspective. It's not that Uber needs all those engineers. It's just a question of marginal cost vs marginal return. Uber made 1.5 billion in revenue in 2015. An engineer costs roughly $150k / yr. An additional 100 engineers only have to make enough small improvements to increase revenue by 1% to pay for themselves.

acchow 10y ago
> An engineer costs roughly $150k / yr This number is far too low. Uber is headquartered in San Francisco.

inputcoffee 10y ago

A lot of the work is convincing people: 1. Convince customers to download the app, give their credit card, and then trust their rides and selves to a driver 2. Convince drivers to clean up their cars, download the driver app, and turn it on, and wait for customers to ask them for rides

deleted 10y ago

[deleted]

hinkley 10y ago

As an inexperienced engineer I did the same thing. My punishment for my hubris was to have bizdevs who felt the same way about us. The weird thing is though, I still actively encourage new devs to make this mistake in certain circumstances. For one thing, telling them no isn't going to help, we have no shared context, and the math of their productivity versus mine works against me spending too much time convincing them. If the problem has a logistical or bureaucratic component, once in a while the stars align and they manage to pull off something the department has been trying to do for years but always runs into a wall. Some people in an organization will assume something is true if they hear it from enough independent parties. I know if three people ask me the same question about a block of our code, I start looking at that code suspiciously. Clearly something is wrong with it. Sending the 5th guy to ask some IT guy or product manager he same question, especially in the way a new person tends to formulate questions, sometimes knocks the cobwebs off and the person decides to change their behavior or volunteer to do something they have resisted doing before. A week of junior dev time for a 5% chance to clear out a bag of tech debt is a good investment IMO. And if it doesn't work they learn something about why things are the way they are. I had a senior coworker who used to laugh and say "You're new here aren't you?" and I started giving him grief for doing it. Sometimes the new guy is the only one who can get things changed.

dancek 10y ago
Great insight there. Additionally, the new guy will be much happier when he's treated the way you suggest. I know I would have appreciated that instead of the bs I got at my first proper job in the beginning.
bonniemuffin 10y ago
I always try to point out to the junior folks when a thing is janky and broken for "historical" reasons rather than technical reasons, in the hope that their fresh eyes on the problem will find a better solution. Sometimes we're still just coasting on the best solution we could come up with 2 years ago, and in those cases it's likely that we could do better if we re-think the problem from scratch.

wslh 10y ago

I think you can ask a simpler question: how do you get traction, drivers and passengers included? You application will be invisible, nobody will see it.

sbov 10y ago

And my answer to your question is: your reply is pretty far off base. Quite simply: when Uber first launch, Uber was not the Uber you are describing. Telling an engineer they need all these things from the start is completely wrong. Yes, competing with Uber now, with "this can be done in a weekend", is naive. But that's not the point. The point is, that there are plenty of problems you can make a lot of money on, with a timeline anywhere from a week to a year. Some will be sustainable, and some will be simple cash grabs. The hardest part is identifying not just what, but when. If you have enough connections in the industry, it can be much easier to predict this than if you are on the outside of things. I have built plenty of things people would say "I could do it in a weekend". And yes, a weekend is a little short, but many of them took just a week, at least initially. The answer is not "Uber does all these things, you need to too." The answer is, "you need to predict the next Uber, so you don't have to do all the things Uber currently does."

sumitgt 10y ago

ALso, they are literally trying to solve a problem similar to the travelling salesman problem when you consider Uber Pool scheduling, Uber Eats, etc.

pjlegato 10y ago
True, but they don't have to find the optimal solution, or even anything close to it. They just have to find a solution that's slightly better than the next-best solution, which in most cases is very far from optimal.

carc 10y ago

I think a related thing people say (that makes me cringe) is that xyz is "just a CRUD app", quite dismissively. You could argue that the vast majority of applications are "just CRUD apps"! Once you get up to a certain scale, even "basic CRUD apps" are complicated.

spynxic 10y ago

Thanks for the nice specifications!

downandout 10y ago

You couldn't build the Uber of today without significant resources, however you could indeed build the version of Uber that made them popular and got them access to those resources in a weekend. Uber started out as a black car app. They got lucky, went viral, and the founders were well connected enough to get funding to build out much of the advanced functionality you're referring to after the app already became popular. It isn't the advanced functionality and scalability you're talking about here (that was built in reaction to its popularity) that made it popular. It was their MVP.

InclinedPlane 10y ago

Even more than that: code is only a tiny part of a tech business, even one that has code as its most critical foundation. A classic example is banking or money transfers (like paypal). So many people think that financial services are nothing more than moving bits around, which seems like an easy thing to code. Aside from the fact that it's not as easy to code as one might imagine, that part is maybe only 1-5% of the business. Paypal got where they are not because of the quality of their code or their operations but because of their relationships. They established relationships with banks, with regulatory agencies, with governments, and they spent years and years doing these things. They signed contracts, they established trust, they created systems for interfacing with many different banks and governments (not just tech systems, but policies and personnel). The result is that paypal is now one of the easiest ways to move money around the world with minimal friction. Cloning paypal's tech wouldn't enable you to clone their success, for those reasons. Same thing with Amazon. Amazon's user facing software is only a fraction of their operations, their main competitive advantages are selection, price, fast fulfillment, and customer service.

developer2 10y ago

You're going to talk about Uber? Watch this video: [1]. He talks about every regret regarding their infrastructure. At first you kind of nod your head along with "yeah, it's not that easy", but as he keeps talking you can't help but wonder why the company has absolutely no internal technical direction whatsoever. They employ over 2000 engineers (just devs, excluding support staff, etc.). They use micro-services designed to the point where teams can't reuse pre-existing services. They are rewriting the same functionality over and over, and over and over again, as separate teams don't even have a clue what has already been written. Pick a piece of functionality you need. There are straight up 20 different APIs that do the exact same thing, but good luck figuring out which one you should be using - oh wait, why bother when you can just write the 21st version of the same thing. They are at the point where they have no clue what their repositories contain. In the video, he can't even provide an accurate number of deployed micro-services. THEY CANNOT EVEN ASSESS WHAT THEY ARE RUNNING IN PRODUCTION. They're literally drowning, and cannot recover. The point of the article is wrong. It's not about what can be done in one weekend, it's what can be done in 12-24 months by a competent team. Yes, Uber operates internationally which comes with a very crazy set of challenges. 2000 engineers worth of challenge? Not even remotely close. You should need fewer than 100 people who really know what they're doing, and another 300-400 people who can follow the lead of the first 100. If you need more than that for a single product (ie: Google does not apply as they have 100+ full products), you are doing things wrong. If you're going to provide the anti-thesis, don't use Uber as your example. They don't even understand how their business is managing to remain afloat from a technical perspective. [1] https://www.youtube.com/watch?v=kb-m2fasdDY https://www.youtube.com/watch?v=kb-m2fasdDY

throwawayuber 10y ago
> They use micro-services designed to the point where teams can't reuse pre-existing services. They are rewriting the same functionality over and over, and over and over again, as separate teams don't even have a clue what has already been written. That's quite an exaggeration. Sure, there is duplication, because Uber has chosen one side of the trade off (duplication) as better than the other (coordination, blocking). I can tell you we don't have 21 versions of the same thing. By the way, what are the chances of building a 500+ person team without hiring a few duds? With such a large team you'd expect a regression toward the mean. Uber only has one product? - UberX - Pool - Commute - Hop - Rush - Eats - Taxi Each of those products is customized in the city or region that it operates in. For example, airports are FIFO queues [1]. At certain airports (e.g. SFO) you can choose from pre-filled destinations like "Departures Level 2, Door 10". Forward dispatch preemptively matches drivers to their next client to minimize downtime [2]. Riders who are late to the pickup get charged on a time basis [3]. You can schedule rides in advance [4]. Sure, a dedicated team could replicate some of these features, but those are just the features that launched. There are TONS of features that launch in only one city, or only to a subset of drivers, or whatever. Which is more likely? That every tech company like Twitter, Square, Slack, Uber, Lyft, AirBNB, Dropbox, Github, Instacart, Stripe (all "one product" companies) are mismanaged or that you don't understand the complexity of running an actual large growing business? [1]: https://newsroom.uber.com/australia/first-in-first-out-airport-queues/ https://newsroom.uber.com/australia/first-in-first-out-airpo... [2]: https://newsroom.uber.com/sri-lanka/forwarddispatch/ https://newsroom.uber.com/sri-lanka/forwarddispatch/ [3]: https://www.yahoo.com/tech/uber-hit-penalty-ride-3-minutes-200241386.html https://www.yahoo.com/tech/uber-hit-penalty-ride-3-minutes-2... [4]: https://www.uber.com/info/scheduled-rides/ https://www.uber.com/info/scheduled-rides/

aagha 10y ago

And on top of all of that, can you get 100K people to use your app?!

imagist 10y ago

I think you're making a related mistake, which is to overestimate the importance of the tech to the business. When Uber first released, my guess is they probably couldn't do most of what you list above. But it didn't matter, because they had one compelling feature: they routed around regulation. This allowed them to pay drivers more and charge riders less than traditional taxis, while taking a cut for themselves. This is a clearly profitable position to be in, which means that they have the money to bring in capable business analysts and programmers, and the rest of what you say above will happen naturally. The taxi apps before Uber didn't recognize that the killer feature was routing around regulation, and the taxi apps after that didn't do it first. Sure, I can't write Uber in its current state in a weekend, but I could absolutely write Uber's minimum viable product in a few days. The problem is having the right combination of a good idea, the correct understanding of why it's a good idea, and the expertise to execute it (not just technical expertise).

rimantas 10y ago

I think you chose a bad example. Imho Uber has waaay to many engineers for what they are doing: to the point where they need to invent work for themselves with no business value.