Hacker News Reader

Comment by xyzzy4 | Hacker News Reader

It seems the Uber app was extremely over-engineered. Call me crazy but I don't think you need 100 engineers to recreate the front-end of Uber.

View on HN

Well your not taking into account all the A/B tests they are running, the fact that they have custom experiences for different locations (SFO, India, etc). I can easily see how they would get up to that number pretty quickly at the scale they are at.

If you have the app, move your map pin to a different city / country to see how it changes. Lots of little and interesting changes depending on which part of the world you're in.

At some point, consider the use of different apps altogether. Perhaps having a front loader to detect which local app should pop up based on information gleaned from the phone and GPS.

What would be the criteria for splitting something out? They do this with uber eats but I can't imagine them doing this for anything else.

Why would I as a user want to download a variety of separate apps to hail cars, etc in different locations? People got really pissed off when Messenger was split out of Facebook (it's still mentioned in app store reviews to this day) I'd imagine they would not be wild about Uber doing something similar. I could see this getting really annoying really quickly.

Imagine landing at a new airport and having to download a new app just to hail a car or a tuk tuk or whatever.

From a user perspective, you may not have to download a new app.

Different locale, different customs, regulations may dictate entire different screens.

How an "app" is designed and packaged internally to enable the business to respond quickly does not have to impact the use experience. There are plenty of design patterns and engineering experience to draw from. It's a somewhat boring topic.

I find it more interesting to find answers to question such as:

1. A native person in India will be presented with an "Indian" app, satisfying the locale, regulations, laws, culture, etc.

2. A tourist landing in India, well, er, what version should that person use? Laws, regulations still apply (well, Uber may have a different take :) ) but how about the user experience and colloquial details? Would the tourist prefer something from home or something that more accurately, and perhaps more apt for India?

So why is this better from a user or engineering perspective than having just one app?

"There are plenty of design patterns and engineering experience to draw from. It's a somewhat boring topic."

I disagree, I think its a fascinating topic but then again I might be biased as I'm a mobile developer ;) Very few organizations have single app's that are worked on by > 50 people. I worked on the FB iOS app for several years. When an app gets that big you run into all sorts of problems that are not obvious both from an engineering and product perspective.

So to me it's pretty interesting to read about how Uber tackled these problems. Especially as it pertains to Swift which has had quite a number of performance issues and language changes.

"1. A native person in India will be presented with an "Indian" app, satisfying the locale, regulations, laws, culture, etc."

Why not have the app detect that and adapt to that user rather than having a separate app?

"2. A tourist landing in India, well, er, what version should that person use? Laws, regulations still apply (well, Uber may have a different take :) ) but how about the user experience and colloquial details? Would the tourist prefer something from home or something that more accurately, and perhaps more apt for India?"

When you land at a different airport currently uber provides a customized experience for that airport/locale. It knows that you are in a different local.

I think you two are saying the same thing. First sentence of the parent comment is:

"From a user perspective, you may not have to download a new app."

Point is that even if it isn't a separate download, in different locale's, it may be essentially a separate app with different screens and UIs.

Sorry maybe I'm misunderstanding what he originally said. I thought he meant break the uber app up into seperare sub apps.

What you describe is what uber currently does?

Well that's not going to save engineering resources and will also be worse for users.

It seems like they've broken into teams organized around features where teams own their feature in all locales. I think that's a better decomposition than one around centered around locales. Centering development around locale is actually incredibly absurd.

> Call me crazy but I don't think you need 100 engineers to recreate the front-end of Uber.

Your sentiment is valid, but consider this: whenever you're working with a project with a ton of money on the table, it becomes possible to add small bits of functionality which more than pay for themselves in terms of return on investment for the engineering effort. This is why you can often write a basic version of a more established application in "a weekend". We've had extensive discussion and meditation on this topic on HN before[1]. Basically apps will grow and add features as long as the engineering effort will pay for itself (I suppose I use that term loosely in this case).

Also consider that the UX is different in different markets, and the reason for that is related to the first issue.

I sympathize with what you're saying, though, and couldn't help but think about Alan Kay's talk that we discussed the other day, about natural complexity vs artificial complication.[2]

[1] https://news.ycombinator.com/item?id=12626314 [2] https://news.ycombinator.com/item?id=14188759

Any software from a big company like Uber, Facebook, Google, etc. is far more complex than what you see. There are typically dozens of features and experiments rolled out to some users and not others. There is also a lot of work necessary to serve so many different markets, such as localization and internationalization. Furthermore, in Uber's case they have a lot more iOS applications than the ones riders use. In terms of complexity, Uber iOS apps are probably comparable to Facebook's apps.

It's definitely a lot of engineers. But we cram a lot of features into the app. I expect that most people will only experience 10% of them. Consider: 1) We exist in a tonne of countries. And different counties often require different product optimizations and payment methods 2) We have our own map provider 3) We experiment with everything 4) We support countries that have terrible networking. That creates lots of challenges.

From an engineering perspective, that sounds uninteresting :)

Terrible networking? how many engineers does it take to implement a few flavors of retries? :)

Uber growth in term of getting drivers, that's what I want to know. It's not just ride subsidies, but the flow of investor honey helps, of course, but they do have some alpha growth managers.

Oh, it goes well beyond retries. You have issues like unpredictable latencies and lost network connectivity. A feature that works great when RTT is 400ms may require an entirely different approach when RTT is 30000ms. There are also issues with clocks due to both fraud and misconfigured cell towers. India for example has notoriously bad RTT times and Jakarta and several cities in LatAm have issues with clocks.

At scale, across so many different markets, with so many different features, things get complex fast. We want the user experience for both riders and drivers to be magical. More magic requires more engineering. The goal is transportation as reliable and available as running water everywhere all the time.

Here's an example of telematics engineering used to improve safety by detecting harsh braking: https://eng.uber.com/telematics/

We also use the IMU measurements to detect drivers who aren't using a phone mount and are instead holding their iPhones while driving.

Features like these allow us to advise drivers on how to be safer and get better ratings since not using a phone mount and harsh braking both correlate with negative user ratings.

A lot more goes into the Uber app to make things magical. I used to read the front page of HN daily to read about all the cool things people around are working on. Since joining Uber, I check far less often now because there are so many cool problems being worked on internally that many of the front page stories sometimes seem quaint in comparison (not that many HNers aren't working on awesome things but the quantity and quality of cool problems my colleagues work on easily captures most of my attention these days).

The best way I can describe working at Uber: it's like building that transportation component of sim-city for every city, everywhere, but it's not a simulation. Despite all the click bait negative press, its bar none the best place I've ever worked.

It is easy to get lost in your work and think it is special. Prior to uber, I've seen quite a bit, and I can tell you certain some are good and certain stuff are not that good

Completely agree that not everything is sunshine and happiness at Uber. The quality is highly variable across the company, but my observation has been that this is a feature, not a bug. Some systems need to be built very well such as software defined networking and container infrastructure, so you need to take the time to build it right. Other areas are one off features where speed to market matters most. Faster, Cheaper, Better, choose two. I would say on average there is a good balance between those three across the company, with each team/project making the right trade offs for the short and long term business goals. Most systems that have proven valuable end up being rewritten. I've helped sunset two older systems thus far.

It's easy to drop in and criticize the architecture of some older systems, but it's also instructive if you were around when they were built and knew the trade offs and constraints that existed when they were first conceived. The growth we've experienced has been astronomical and it would have been non-trivial exercise to build systems 2-3 years ago that account for the scale and business needs today. Even today, it's hard to plan farther that 2-3 years out with the growth we are seeing. I work on a system doing millions of QPS and in 2-3 years, it will be handling an order of magnitude more QPS and more business needs. We might scale horizontally or decide a different solution is needed. I don't think there is a silver bullet and the microservice architecture means that rewrites and re-architectures are tractable problems.

He mentioned in the very beginning that there are city teams, so perhaps it's a number of people proportional (not exponential, like he says) to the growing # of cities.

Hire lots of people... complexity, arcaneness, process and knowledge-hoarding becomes vital to job-security.

also when you need to develop a new feature and it needs to go through A:B testing frameworks, localization (including Arabic Right to Left text/layouts), phased feature roll outs, 99.999% reliability, integration testing, planning for use cases anywhere from LTE/WI-FI in USA to EDGE network in developing countries, and you need to build the tools that do those things too. Clearly the 100 engineers are sitting there twiddling their thumbs.

I think you might of missed the point... everyone has regulations and current problems at any scale, but the ability of BS job roles to hide in a large workforce and for managers to build pyramidal layers of organizations of little added value (but lots of expensive management layers with ever loftier titles).

I think you have been to a few rodeos :)

Yeah, when a team goes from 2 to 100, a serious business/engineering manager got to ask a few questions. However, if money honey flow is not a problem, it could be in everyone's interest just to ride along

They have a few other apps too, right? Driver app, Uber Eats, Uber Freight, etc.

It's basically tens / hundreds of apps rolled into one, with frontends loaded based on your currently stated or GPS location. They all share a common foundation, but features vary wildly depending on city / country.

You're coming at this backwards. They had 100 engineers already. They needed to design their software so that the engineers could all keep working on it. They explicitly say as much:

> This application has served us very well for the past four years. But as we've expanded and exponentially grown our mobile engineering team, we started seeing breakages of the architecture, we started seeing problems where feature development would become pretty hard. We had to test multiple code-paths because we shared a lot of view controllers amongst different teams. We really started to hurt with the old architecture because it was written by two engineers and we had grown the team to over one hundred, at that point.

The actual quality of the software isn't as important, since Uber drivers and riders don't have a choice anyway.

Uber riders have more than one ride-sharing app on their phone. If Uber can't match me to a driver, I'm still going to get where I want to go.

Reply on news.ycombinator.com