Why's that company so big? I could do that in a weekend

The root cause of the development bandwidth problem was that we wasted vast amounts of time and energy on building misfeatures. And we built so many misfeatures because we had way too much development capacity in relation to our product planning capacity. So the BAs didn't have enough time to fully develop ideas before sending them to engineering, and were instead stuck throwing things over the wall when they were still half baked. All these half-baked ideas took time to build, and then they took time to fix after they bombed on the market, and they slowed everything else down since every new feature is something you have to ensure still works when you make a change in that part of the software. Day in, day out, we were taking on technical debt to cover our design debt bills.

So then we tried Agile, and man oh man did that make things worse. 'Cuz now instead of just lobbing things over the wall, the BAs had to be actively involved in every sprint. There goes any opportunity to sit down and concentrate, because now you've got a nattering horde of 20 developers all trying to get clarification on last week's decisions, which leaves less time to make this week's decisions, which means next sprint things will be even more sketchy and ill-defined.

The correct solution would have been to hire more business analysts, and they key thing we needed from those business analysts wasn't instructions on what to build. It was instructions on what _not_ to build.

This is 100% true and unfortunately gets distorted from the financial backers who pump them up for unicorn status. Quite a dichotomy:

"Software is eating the world!"

"The hard thing isn’t setting up an organizational chart. The hard thing is getting people to communicate within the organization that you just designed."

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

I think a big part of the disconnect being discussed originates in the myth that CRUD-based apps are fundamentally easy. This simply isn't true. The challenges of building a modern, complex, scalable CRUD app with good UX and a maintainable code base are not 'less than' challenges rooted in algorithms or bit bashing. Doing it well enough and fast enough to be competitive in the market is HARD.

Uber and Lyft are not just taxi apps. They are massively polished. When I use them I am astounded at how good they've gotten the UX and then I shudder at how hard that must have been across two mobile platforms and in the presence of very unreliable networks. I've ordered an Uber with no cell Internet using barely usable coffee shop wifi from a block away.

Then you have scaling, which brings up or creates issues you just do not see at smaller scales. Big O type considerations and weird edge cases that only come up once every billion transactions start mattering.

Then there is all the big data stuff. These services do tons of route optimization and analytics.

So yeah marketing, sales, fund raising, management, etc. also matter but tech often matters as much or more. It's just that junior engineers usually only see the tops of icebergs. This is why despite decades of pure biz people saying "tech doesn't matter" you still rarely see founding teams succeed without at least some tech founders but you do occasionally see even lone tech founders make it. (But those tech founders do have to know or be willing to learn the non tech stuff!)

> Internalizing that has been difficult for me as an engineer.

After I got over that particular hurdle, I would still think:

Ok, so "build it and they will come" is not a thing, got it. But still, engineering is most important by far. Without sales, support, marketing, or legal, you still have a product, just one that is adopted slower. Without engineering you don't even have a product to sell in the first place.

And that's true. But in the end it's just splitting hairs. It doesn't matter. Over the longer term, no successful, scalable business is ever going to exist solely as an engineering team. Every job function has a purpose[0] and gets you where you want to go faster; in some cases, lack of certain non-engineering job functions will make it impossible to even do certain things.

So sure, you can bootstrap a product with just a few engineers and nothing else, but unless you're ok with it being a niche-market product that you spend all your waking hours working on, an engineering-only org is never going to cut it.

[0] With the obvious exception of those people hired to satisfy the latest management fad du jour, or to give the CEO's deadbeat nephew something to do with his time.

Execs love to think this but it's just not true. Top heavy companies waste money. It's true that tech of not the only ingredient but for a tech company it's critical. Good tech is not a commodity. Top-tier engineers are worth as much as a good CEO. That is if you want to remain lean.

I suspect this is because everyone wants to not only feel as part of something but they want to make an important contribution. I venture to guess accountants at Google do not feel they make a difference to search. The culmination of parts is what makes the company whole and all those parts are required.

Its hard to accept you are not as important as you wish you were. Its a great step in the maturation process of one's professional career though.

Have you considered broadening your personal definition of technology past computing and engineering?

From Wikipedia:

> Technology can be the knowledge of techniques, processes, etc. or it can be embedded in machines, computers, devices and factories, which can be operated by individuals without detailed knowledge of the workings of such things.

Technology is the creation of systems. Those systems run as much on the users of that technology, and the members of the organisation supporting it, as they do inside of microprocessors.

Technology exists largely to accelerate the pace of development and of course, it's never a sole driver of any business. There is no reason why you can't create a small-scale uber with call centres and excel spreadsheets but I doubt it would reach the scale and impact of what Uber is today. Granted that, it's hundred times easier to figure out to technology than business, I won't trivialise role of engineering because it's something allows a business to near its global maximum.

The feeling that the CEO I was working with was doing mundane tasks was astonishingly - he even said that he could to his whole job using his smartphone.

But after trying to do the business stuff myself I realized that no one in all of this process is irreplaceable - finding a good software developer may not be easy, but it's also not easy to find a good CEO. This is important to realize that software developers shouldn't see themselves as some type of elite.

The main problem is that junior devs don't realize that 90% of business is based on networking and being friends with people who are in middle management and want to increase their reputation in their big corp. You don't get big clients because you're a genius hacker, most of the time those B2B applications are simple CRUD apps. You won't get that $500k because you simply didn't play golf with the key partners. I'm not even exaggerating, I've seen that the best deals are made in ones "spare time".

Maybe startups are another breed than the software companies I know, but don't drink the cool aid and don't assume that technology is your main differentiator. It's working with people all along.

I think it isn't even about scaling high-performance systems, it even starts with the mindset of those who think that software developers are entitled in some way, usually junior devs and people who never did any real business work.

Most of the unicorns are founded with engineering talent coming straight from Stanford, MIT, Harvard, UCB, Waterloo etc. you name it.

Making a company successful is as much about economics of scale than raw engineering and of course, both are closely related in this day and age. Engineering shapes what and how your products feels like in real-time (= understand very short code-to-production lifecycle).

It might not be politically correct to say but I am not here to make you feel better. Anyone who has actually been in a team at a company that has exponentially grown will tell you the same: your chances to ever survive that "first wave" of users is directly proportional to your ability to hire the best, which of course is a lot easier when they are your current or former classmates.

That's not to say there aren't companies founded by people not going to the schools mentioned above or that engineering talent is only available at these places. It is obviously not the case.

However, the density of talent at top-schools is absurdly high. And this is a game changer for most early stage companies and even more so for soon-to-be-unicorns.

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.

Isn't ignoring regulations the most often quoted reason for Uber's success?

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.

> 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

There's two ways to interpret this: 1) Uber is overstaffed by an order of magnitude. 2) You are underestimating the complexity of Uber by an order of magnitude.

Uber might be overstaffed, but I suspect the answer is mostly that you are drastically underestimating and don't see the complexities of running a large-scale service in multiple countries, dealing with regulations, worldwide scalability, time and cost estimates, surge pricing, tracking and mapping, payroll, billing, payments, apps, internal IT, etc., etc., etc. There aren't 10-20 "concerns". There are hundreds.

I bet they have at a hundred engineers just working on billing and they're all overworked.

> I don't see any creative ideating that would justify that many engineers

Because most of Uber's engineers aren't there to build "creative" solutions. They're there to enable the business.

Maybe, theoretically, in some cases. But even so that's very different from the original "I could build that..." bloviation.

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.

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.

No way you can delegate work to 2k engineers and tell them what to do for next 2 days. Physically impossible.

This number is far too low. Uber is headquartered in San Francisco.

it is scalable because the bus-stop transmitters are added , moved, removed as needed.

updating the data can also be done remotely

I guess it is easier in the long run to have all routes mapped and instead of GPS you use something like doors open / doors close as a trigger to jump to the next entry.

> For maximal accuracy simply have an electronic beacon of any sort broadcasting an ID that corresponds to the stop and you've got it solved.

That's not remotely accurate for the reason above.

> And the entire data set for the route should be able to live offline onboard the bus. Changing bus/numbers routes should include the step for updating route data.

It can. E.g. the old London system used odometers. But that was sufficient only for showing "next stop ..." and for reporting very rough estimates. Today it uses odometers, gps, rate gyros and turn rate sensors to be able to more accurately position the buses along a route, and they still regularly "give up" and take a bus off the schedule when traffic conditions means the uncertainty is too high.

3G is necessary for live ETA, if you want to get fancy. All these complications, in my view, are worth it if you want a system that works 24/7 and serves thousands of people daily. The HW and SW dev costs are acceptable, but it does need a decent team, depending on what the starting point is and the ability of the team members.

Yeah, and now we need to install and manage thousands of beacons in bus stops in pretty hospitable conditions.

Of course, GPS isnt perfect either. It tends to fail in CBD areas.

I guess the names of the stops are untranslatable anyway :)

The question is what is more work: Using the existing data that is stored in some obscure format for which you first have to write an importer/converter or just recreating the data. Add the fact that the existing data might need some cleanup/additions (e.g. times on timetable are only stored with minute precision and you want second precision for more accuracy).

GPS and 3G/4G are trivial add-ons. There are stacks for mobile data.

RFID doesn't have the reliable range, so that won't work as a solution.

It's not really a hard problem for a competent small engineering team with a mix of embedded hardware and software skills. It's not quite a trivial problem, because there are some interesting edge cases, mostly when a bus is diverted. But there is absolutely zero rocket science required.

You could hack something unreliable together in a weekend, but it would take up to six months to get all the bugs out, do the production engineering for a bullet-proof solution, standardise the installation process (if retrofitted), and so on.

Double that if management is poor. :)

Those last parts often get forgotten in software. Hacking something together that kind of works if you don't look at it with a visible frown is hobby coding, not engineering. Engineering is the boring work that happens after that, to build something with a quantifiable many-9s uptime that meets or exceeds a standard spec with comprehensive test cases.

Source: I don't drive,and ride the bus a lot.

Breaks down quickly if you need bi- or tri-lingual announcements, which is the norm in many popular tourist destinations.

(I calculated the geometric mean of the numbers both of you have given, in case you're wondering ;) )

I'd say something like 3 people for 6 months to 1 year (not all 3 being needed 100% of the time).

That's just faster horses though.

Conductors aren't a solution to a problem in themselves, they're a means to solve a problem. So what's the actual problem? WHY do they want conductors back?

Uber especially has requirements that make it tough to scale correctly. You need to track each Uber session in near real-time, right? That means you simply cannot afford to drop or interrupt those sessions. It's a completely different problem than scaling Instagram or WhatsApp.

I don't think that's really true, especially in a big corporation. Transparency of the value pipeline in such institutions isn't great at any level, and big corps (and similar large institution -- government often has the same problem, for instance) have a tendency toward not making even the concept of the value stream that justifies the position known to the people working in it much of the time. Its quite likely that the people working a position don't understand how its supposed to deliver value (and are in a poor position to see the big picture of whether it does), while the people who do know how it is supposed to deliver value don't see the small picture of what actually goes on (and thus are in a poor position to evaluate whether it does deliver the value it is supposed to.)

There's no particular reason to think the people working in the position are in the best position to evaluate value delivery (or that even the people in the best position, whoever they might be, are better at answering the question than a Magic 8-ball.)

Yeah I know that's his point and that's why I describe his point of view as being naive.

It may be true that for some percentage of workers at any given time their role is experimental and may turn out to be unimportant or a failed attempt at change, and it may be the case that it take a while for these sorts of inefficiencies to be rooted out or resolved because the cost and time associated with doing so make it a low priority but that is something that people who are in those positions would not necessarily be aware of.

This is the same as when people say things like "I don't know why we are so precious with our kids these days. I never wore a bike helmet and I survived!".

Without the proper perspective people frequently form wildly inaccurate opinions.

I don't think he thinks "anyone not involved in hammering steel" is unnecessary, that's a bit of a strawman.

If all I have to do in order to make it a straw man is replace the word iPhone with horseshoe he's doing a pretty good job of constructing his own straw man.

The argument goes that big corporations have a tendency to hire more people than necessary because middle managers are rewarded based on how many people work under them. Or that people looking to keep their jobs, try to make themselves look more busy and valuable than they really are.

That story is completely ridiculous.

People waste a lot of time at offices doing things that aren't work. But our culture demands we be at work 8 hours a day, even if the work only requires 4 hours.

Then businesses have an opportunity to compete for talent by offering better working conditions. If they can do so profitably then they win.

Economists in the 1930's thought the world would be so rich by today, that people would only need to work a few hours a week. And the economy has grown vastly since then, and we are much richer. But I don't think most people have the option of working that little, even if they want to.

This is more a result of the spoils of productivity increases not being distributed evenly.

By having massive unemployment and under employment then expecting the remaining workers to work harder for less pay on average while more and more income is paid towards servicing private debt the finance, banking and real estate sectors have made out like bandits.

But that's a different subject entirely from automation.

I don't think so. It has a lot to do with automation because that is where the productivity increases have come from, but rather than the federal government guaranteeing full employment and setting a floor price for labour and a minimum set of conditions below which we consider employment to be exploitation, which would not only maintain demand in the economy but also reduce the inequality with which the spoils of those productivity increases are distributed, they have left people to fend for themselves and the economy has languished as a result.

Those jobs can really be valuable and still be vulnerable to automation. AI has improved a lot in the last 5 years. I don't think it's implausible at all to imagine most jobs done now being partially or totally automated.

Maybe in 1,000 years but I disagree that automation will have the type of impact people (particularly in the UBI advocacy camp) claim it will.

So maybe we shouldn't complain. These websites are just meant to be zoomed.

Although some web developers are cruel and block zoom with meta tag (I never understood why some developers did that, maybe for trolling people with poor sight?).