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.
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.
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.
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.
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.
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".
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.
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).
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.
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.
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."
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".
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.
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 !
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.
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.
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.
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.
> 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?
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.
This is such a straw man conversation. Of course it is a fallacy to think "I could build that in weekend" and translate that to a claim about the inefficiency of a company. I think that's what is being responded to in this thread. But that's not the interesting debate.
A better consideration (imho) is this:
For a given business/offering/product, what is a likely optimal number of engineers needed to continuously deliver the product's value efficiently? Then: How far is a given company from that optimal number?
This is a hard analysis to do. It is virtually impossible to quantify or put this kind of evaluation in a laboratory. There are too many counterfactuals that would be at play.
We really just have to consult our experience and consider which of these is the more probable:
(1) A business/offering/product team with lots of money is really good at utilizing its hundreds of staff.
OR
(2) It's not.
I've seen a few (2)s from the inside. I have never seen a (1). Therefore I lean more probabilistically toward the belief that a company is needlessly big.
What surprises me is that that's not where people on this thread are leaning---but has anyone on this thread actually ever seen a (1)??? If not, where is this belief coming from? I've never seen a ghost, so I don't believe in ghosts....
Consider, for the sake of argument, the possibility that perfect efficiency is unachievable. Almost physically impossible. As a company gets larger, certain kinds of inefficiency in hiring and utilization become absolutely inevitable. With that premise in mind, how many employees does a company "need"? If it would need fifty in that universe of perfect inelastic spheres with no friction or similar effects, how many times that does it actually need in the real world of such efficiency-robbing factors?
In my experience, the answer is two at best and more often, around five. The incremental work product from each new hire diminishes more rapidly than many realize, but the incremental revenue might still make such hires worth it. As Dan points out, a few percent increase in efficiency from optimization can be huge. It might take multiple people quite a while to achieve that, and it will still be worth it. There might be another group of several people trying something else that doesn't pan out, but that doesn't mean they were unproductive dead weight either. Bigger companies have to take risks too. They just take them differently, and the cost is more obviously attributed to them instead of the market.
Maybe a single startup could do what Twitter (for example) does, in fairly short order. Even that's unlikely when issues of scale etc. are considered, but that's not even the point. That single startup is not a valid point of comparison, because it doesn't count the cost of failed experiments. Add up all of the startups trying to do what Twitter does, including the failures, and that probably be a better estimate of how big Twitter (Uber, Netflix, whatever) needs to be.
Well, I think one of the best points the article made was essentially: A company will continue hiring more people as long as the extra profit from an engineer outweighs the cost.
This isn't literally true in all cases, but it points out that the business decision of how large to grow is based more on that sort of reasoning than "what's the minimum team that can get X done", and maybe a bit different than the analysis you propose.
There's a naïveté in saying "I could do that in a weekend" as a measure for employee bloat, but that's making a straw man of the question.
It is nearly always more probable that a large company with several hundred or more plus engineers doesn't need that many. That those engineers are there for other reasons -- political reasons or speculating on new products, valuation reasons, etc. -- than for the reason that those engineers are fundamental to the top or bottom line of the company's core product/s.
Uber does not need 2000 engineers. That's a prima facie fact.
I've worked inside several large companies and saw this first hand. Hundreds of engineers across teams doing "stuff", no doubt, but nothing that ultimately or ever tied to the top or bottom line. The only ideas that I could come up with for why these people were there were: perhaps the headcount helped company valuation, perhaps we needed that many benchwarmers for when there was company churn, maybe there is some political reasons a manager wants a sizeable headcount on their team, or maybe it's just leadership ignorance as to how things are getting delivered. But in no way could I see a concrete justification for many teams and many engineers.
I searched for GTGACCTTGGGCAAGTTACTTAACCTCTCTGTGCCTCAGTTTCCTCATCTGTAAAATGGGGATAATA and found another post by the same author on another website http://bitfunnel.org/strangeloop/
I've seen some other posts by Dan before but didn't know what kind of things he works on because I generally don't check that because if I did then I'd end up just checking people instead of reading what people were writing. Anyhow, from the article linked above -- for which a video is available at https://www.youtube.com/watch?v=80LKF2qph6I -- it turns out that Dan has done quite a bit of work with implementing search related technology, and I think that was interesting. His contributions to BitFunnel can be seen at https://github.com/BitFunnel/BitFunnel/graphs/contributors
The other side of the coin is that big companies do move slow.
There is a lot of communication overheads, a lot of bureaucracy, backwards and cross compatibility concerns, conservatism, wasted duplicate effort, wasted pointless effort, some people who aren't contributing much etc. etc.
This is why tiny startups can sometimes dethrone a large leader. However that's often a multi-man-year effort.
So I'd rephrase the statement: "Why's that company so big? I could do that with 20 brilliant engineers and 18 months". I think that order of magnitude can attack pieces of any established software business from a technical perspective. Then there's obviously the business side.
Yup. Have never gotten the whole "Airbnb/Uber/<startup>" is just a crud app line of thought.
If they're crud apps then everything else in between is just glue programming.
The author of the post covered some very astute points but one not covered in much detail is the challenge of scale and reliability. Maybe this falls under the bucket of optimization and/or latency but I think this deserves being called out on its own.
Once you have Uber-scale number of users requesting taxis at any point, and have a network of drivers constantly communicating their position with the app, suddenly you no longer have a trivial crud app on your hands...
To me this is a form of the Dunning-Kruger effect[0], where only somewhat informed people estimate the cost of a "0.1" (or POC) release without considering the famous "unknown unknowns" which may involve scaling, billing, 3rd party integrations, etc.
And yet sometimes a small team really could do it. I spent years complaining about MSN/AOL/Skype etc. and talking about how a small team could build a better messenger in a week, but we didn't really believe it. Then Slack actually took that possibility seriously, and look at the results.
Actually it actually wrong to assume somebody could solve a trivial problem in a weekend, however some companies still have way too many people working at it.
Consider twitter with their 3860 people. they could probably do it with half of them. especially the technical people are 40% of the company... way too much. i don't think that they need no people but well...
The sad truth is that in the majority of cases the quality or time taken over the implementation isn't particularly important other factors matter much more:
* building something people actually want.
* advertising
* engaging with users
* aggressively promoting your product.
* customer service
It doesn't matter if what you did was hard or not. It matters that you can acquire and retain customers.
> Businesses should keep adding engineers to work on optimization until the cost of adding an engineering equals the revenue gain plus the cost savings at the margin. This is often many more engineers than people realize.
I think this is the key realization, and it's actually a variation on Conway's Law[0]. In a nutshell, some part of BigCorp discovers (or believes) that by hiring a software developer for $X, they can make $Y > $X in return. So they do.
As long as some part of BigCorp is able to do that, you get more software engineers. This continues until you either (a) run out of budget, or (b) run out of opportunities.
Because it's not done "top down", it less efficient than it could be to get all of the features in total. But due to how these engineers are funded internally, it's not possible to do the "top down" approach at all. And that's okay, all that really matters is that $Y > $X.
[0] https://en.wikipedia.org/wiki/Conway%27s_law "Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." In this case, it's not the communication structure that causes the perceived bloat, it's the funding mechanism. The basic idea that software organizations reflect some non-software, human structure in the business, holds.
Everything seems easier when you're not doing it yourself. It's only a minor variation on the grass being greener. Everything gets way more complicated when you're doing it at scale, with high reliability, for real users, with some hope of making money. Practically nobody adds complexity for its own sake. Usually, if you think something is much more complicated than it needs to be, it's because you don't have any idea what the real requirements and constraints are.
To me this post addresses the same naivety that David Graeber demonstrates when he claims that everyone not involved in hammering out a sheet of steel to make a horseshoe or pulling a plough is engaged in a bullshit job[1].
I think it's not a coincidence, therefore that many of the people I run into who advocate a universal basic income, arguing tooth and nail against a job guarantee (the YC guys no different) is young, tech savvy and overly optimistic about the scope of automation to subsume all human labour within months.
Completely unrelated to the article, but I'm curious what people's thoughts are on full-width lines of text characteristic of unstyled HTML.
I've seen some[1] bemoan its impacts on readability and others[2] complain about websites which artificially restrict themselves to (what can be) a narrow slice of the viewport.
>>There’s also a wide body of research that’s found that decreasing latency has a roughly linear effect on revenue over a pretty wide range of latencies and businesses.
Otherwise, indeed, it's a basic evaluation error, as described as long ago as in the The Mythical Man-Month; it just seems that nowadays, the multiplier is not 9, but even bigger.
I have worked with one-man companies that did this and often they are shoddy products. Healthcare just seems to suck at software.
Full-stack developers are already a very fast evolution from the front/back end developers, which were an evolution from a guy doing just HTML/CSS in the 90s. Now you have to include sales, marketing, negotiation, project management, and business management skills on top of your full-stack development skills. The result is that something is going to suffer unless you are a genius, the product is super-simple, or you have 20-30 years to have learned all of this.
There's a much more interesting question in the form of: "Why's that company so big? A tight-knit team could do that in a weekend".
[+] [-] malux85|9 years ago|reply
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?
[+] [-] rfrey|9 years ago|reply
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.
[+] [-] hinkley|9 years ago|reply
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.
[+] [-] dagw|9 years ago|reply
[+] [-] developer2|9 years ago|reply
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
[+] [-] AlexandrB|9 years ago|reply
[1] http://www.zdnet.com/article/uber-to-invest-500m-in-mapping-...
[+] [-] novaleaf|9 years ago|reply
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.
[+] [-] imagist|9 years ago|reply
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).
[+] [-] downandout|9 years ago|reply
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.
[+] [-] wellpast|9 years ago|reply
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.
[+] [-] sbov|9 years ago|reply
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."
[+] [-] emilsedgh|9 years ago|reply
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?
[+] [-] esrauch|9 years ago|reply
[+] [-] usgroup|9 years ago|reply
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 !
[+] [-] wslh|9 years ago|reply
[+] [-] madeofpalk|9 years ago|reply
[+] [-] InclinedPlane|9 years ago|reply
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.
[+] [-] forgetsusername|9 years ago|reply
You underestimate the amount of luck involved in becoming Uber. It's not all luck, but luck is a major factor.
[+] [-] erjjones|9 years ago|reply
[+] [-] carc|9 years ago|reply
[+] [-] inputcoffee|9 years ago|reply
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
[+] [-] 20years|9 years ago|reply
[+] [-] taco_emoji|9 years ago|reply
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?
[+] [-] amelius|9 years ago|reply
Anyway, here's a related link: https://www.quora.com/Why-do-AirBnb-and-Uber-need-so-many-en...
And here another: https://news.ycombinator.com/item?id=12597232
[+] [-] mgalka|9 years ago|reply
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.
[+] [-] sumitgt|9 years ago|reply
[+] [-] kenjackson|9 years ago|reply
[+] [-] andrei_says_|9 years ago|reply
[+] [-] fail2fail2ban|9 years ago|reply
[+] [-] systemtest|9 years ago|reply
Think a bit further:
- Hardware needs to be resistant to harsh diesel engine vibrations
- 3G/4G connectivity
- Need a mobile data contract with local ISP
- Software needs to be able to handle network disconnections
- GPS needs to be able to pin-point at which stop the bus is currently stopped, even with bad GPS coverage in larger cities
- If the bus skips a stop because of a detour, the software should be able to detect it and announce the next stop
- The announcement should be bi-lingual for Airport busses
- The announcement should work for people with hearing aids
- Server needs to know all bus-stops
- Server needs to know different stop types, such as bus terminals, intersection stops, regular stops, hand-over stops, virtual stops
- Server needs to be able both work of a yearly bus schedule and real-time update
- Server needs to output in an understandable JSON/XML because the government subsidies demand an open-data format
- Server needs to publish data to an open-data server because of the subsidies
- Because the bus-company is sponsored by European Union money the control interface should be translated to German/French/English/Spanish
And now this weekend project takes a team of 10 engineers working for a year.
[+] [-] wellpast|9 years ago|reply
A better consideration (imho) is this:
This is a hard analysis to do. It is virtually impossible to quantify or put this kind of evaluation in a laboratory. There are too many counterfactuals that would be at play.We really just have to consult our experience and consider which of these is the more probable:
(1) A business/offering/product team with lots of money is really good at utilizing its hundreds of staff. OR (2) It's not.
I've seen a few (2)s from the inside. I have never seen a (1). Therefore I lean more probabilistically toward the belief that a company is needlessly big.
What surprises me is that that's not where people on this thread are leaning---but has anyone on this thread actually ever seen a (1)??? If not, where is this belief coming from? I've never seen a ghost, so I don't believe in ghosts....
[+] [-] notacoward|9 years ago|reply
In my experience, the answer is two at best and more often, around five. The incremental work product from each new hire diminishes more rapidly than many realize, but the incremental revenue might still make such hires worth it. As Dan points out, a few percent increase in efficiency from optimization can be huge. It might take multiple people quite a while to achieve that, and it will still be worth it. There might be another group of several people trying something else that doesn't pan out, but that doesn't mean they were unproductive dead weight either. Bigger companies have to take risks too. They just take them differently, and the cost is more obviously attributed to them instead of the market.
Maybe a single startup could do what Twitter (for example) does, in fairly short order. Even that's unlikely when issues of scale etc. are considered, but that's not even the point. That single startup is not a valid point of comparison, because it doesn't count the cost of failed experiments. Add up all of the startups trying to do what Twitter does, including the failures, and that probably be a better estimate of how big Twitter (Uber, Netflix, whatever) needs to be.
[+] [-] bo1024|9 years ago|reply
This isn't literally true in all cases, but it points out that the business decision of how large to grow is based more on that sort of reasoning than "what's the minimum team that can get X done", and maybe a bit different than the analysis you propose.
[+] [-] wellpast|9 years ago|reply
It is nearly always more probable that a large company with several hundred or more plus engineers doesn't need that many. That those engineers are there for other reasons -- political reasons or speculating on new products, valuation reasons, etc. -- than for the reason that those engineers are fundamental to the top or bottom line of the company's core product/s.
Uber does not need 2000 engineers. That's a prima facie fact.
I've worked inside several large companies and saw this first hand. Hundreds of engineers across teams doing "stuff", no doubt, but nothing that ultimately or ever tied to the top or bottom line. The only ideas that I could come up with for why these people were there were: perhaps the headcount helped company valuation, perhaps we needed that many benchwarmers for when there was company churn, maybe there is some political reasons a manager wants a sizeable headcount on their team, or maybe it's just leadership ignorance as to how things are getting delivered. But in no way could I see a concrete justification for many teams and many engineers.
What am I missing?
[+] [-] eriknstr|9 years ago|reply
I've seen some other posts by Dan before but didn't know what kind of things he works on because I generally don't check that because if I did then I'd end up just checking people instead of reading what people were writing. Anyhow, from the article linked above -- for which a video is available at https://www.youtube.com/watch?v=80LKF2qph6I -- it turns out that Dan has done quite a bit of work with implementing search related technology, and I think that was interesting. His contributions to BitFunnel can be seen at https://github.com/BitFunnel/BitFunnel/graphs/contributors
[+] [-] YZF|9 years ago|reply
There is a lot of communication overheads, a lot of bureaucracy, backwards and cross compatibility concerns, conservatism, wasted duplicate effort, wasted pointless effort, some people who aren't contributing much etc. etc.
This is why tiny startups can sometimes dethrone a large leader. However that's often a multi-man-year effort.
So I'd rephrase the statement: "Why's that company so big? I could do that with 20 brilliant engineers and 18 months". I think that order of magnitude can attack pieces of any established software business from a technical perspective. Then there's obviously the business side.
[+] [-] yomly|9 years ago|reply
If they're crud apps then everything else in between is just glue programming.
The author of the post covered some very astute points but one not covered in much detail is the challenge of scale and reliability. Maybe this falls under the bucket of optimization and/or latency but I think this deserves being called out on its own.
Once you have Uber-scale number of users requesting taxis at any point, and have a network of drivers constantly communicating their position with the app, suddenly you no longer have a trivial crud app on your hands...
[+] [-] bsandert|9 years ago|reply
[0]: https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
[+] [-] lmm|9 years ago|reply
[+] [-] merb|9 years ago|reply
[+] [-] new299|9 years ago|reply
* building something people actually want. * advertising * engaging with users * aggressively promoting your product. * customer service
It doesn't matter if what you did was hard or not. It matters that you can acquire and retain customers.
[+] [-] erichocean|9 years ago|reply
I think this is the key realization, and it's actually a variation on Conway's Law[0]. In a nutshell, some part of BigCorp discovers (or believes) that by hiring a software developer for $X, they can make $Y > $X in return. So they do.
As long as some part of BigCorp is able to do that, you get more software engineers. This continues until you either (a) run out of budget, or (b) run out of opportunities.
Because it's not done "top down", it less efficient than it could be to get all of the features in total. But due to how these engineers are funded internally, it's not possible to do the "top down" approach at all. And that's okay, all that really matters is that $Y > $X.
[0] https://en.wikipedia.org/wiki/Conway%27s_law "Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." In this case, it's not the communication structure that causes the perceived bloat, it's the funding mechanism. The basic idea that software organizations reflect some non-software, human structure in the business, holds.
[+] [-] Animats|9 years ago|reply
Then came search customization. Suddenly, no more cached replies.
[+] [-] notacoward|9 years ago|reply
[+] [-] dools|9 years ago|reply
I think it's not a coincidence, therefore that many of the people I run into who advocate a universal basic income, arguing tooth and nail against a job guarantee (the YC guys no different) is young, tech savvy and overly optimistic about the scope of automation to subsume all human labour within months.
[1] http://strikemag.org/bullshit-jobs/
[+] [-] ErikAugust|9 years ago|reply
"Why not use [Example OSS Library]?"
"Nah, I can do it in 15 minutes."
"You know, they have [X] contributors, lots of great documentation, and 6 months of work into it."
"Yeah, I know [but whatever.]"
[+] [-] azdavis|9 years ago|reply
I've seen some[1] bemoan its impacts on readability and others[2] complain about websites which artificially restrict themselves to (what can be) a narrow slice of the viewport.
[1]: http://bettermotherfuckingwebsite.com
[2]: https://plus.google.com/+LinusTorvalds/posts/2Ndtw3ZBRX2
[+] [-] VestingAxis|9 years ago|reply
Anyone have pointers to such research?
[+] [-] informatimago|9 years ago|reply
https://archive.org/details/mythicalmanmonth00fred Figure 1.1, page 5
To go from a program to a programming system (interfaces, system integration), you need to multiply the effort by 3.
To go from a program to a programming product (generalization, testing, documentation, maintainance), you need to multiply the effort by 3.
So to get a programming system product, you need to multiply the effort from the program step, by 9.
Nowadays, we need to compose indeed multipliers for distribution, reliability, availability, localization, targetting multiple UI platforms, etc.
And the original multipliers are also probably too small, when you see the effort required just to integrate testing and CI on some projects.
[+] [-] FLUX-YOU|9 years ago|reply
Full-stack developers are already a very fast evolution from the front/back end developers, which were an evolution from a guy doing just HTML/CSS in the 90s. Now you have to include sales, marketing, negotiation, project management, and business management skills on top of your full-stack development skills. The result is that something is going to suffer unless you are a genius, the product is super-simple, or you have 20-30 years to have learned all of this.
There's a much more interesting question in the form of: "Why's that company so big? A tight-knit team could do that in a weekend".