But the old Uber app had hit its age limit. It was build on top of technology chosen for a small number of features (ex: a single global DI component, lack of typing, a small MVC hierarchy). So we either needed lots of large migrations or a rewrite. The incremental migrations required to fix these issues would have been extremely disruptive, they wouldn't have gotten us an entirely refreshed UI and they wouldn't have given us a number of other benefits.
So we decided to do a rewrite. We had lots of engineers that knew the issues to watch for from the first time we wrote the app. And a handful of us spent months researching/building different architectures, static analysis and tooling that would ensure the rewrites success. We weren't going to repeat the same mistakes twice.
On the very first day the app launched it was more reliable and performant than the version of our app that we had been maintaining for years.
I did assume that in your case the rewrite was valid - after all, you laid out the case. I was just surprised that it went as well as it did - I've seen so many rebuilds that went to shit that it was a genuine shock to see one go well.
While I can't speak for mobile rewrites, many systems at Uber have been rewritten several times as the business needs have changed and we've grown in scale. With each iteration the systems become more general and support a greater scale and a greater variety of business needs. The added complexity of our micro-services architecture has been worthwhile because it's reduced the complexity of making changes to systems that can't be taken offline because they are part of the core trip flow. Basically, it's as if we started with a small glider years ago and have upgraded it into a 777 Dreamliner piece by piece while still flying.
We have also taken advantage of the rewrites to rebuild in Go and Java. Most of our older systems were NodeJS and Python. Many of those have been rewritten in the two languages we've now mostly standardized on.
Pretty much every rewrite I have witnessed has gone well, so I can only guess there's something we're doing right in this respect.
Lots of reasons such as performance, type safety, static analysis, etc. NodeJS worked well when we were smaller, but it's not uncommon to work in code you didn't write and Golang and Java are languages where the compiler helps you a lot.
One of the best policies we have at Uber is our internal transfer policy. So long as you're in good standing perf-wise, you can transfer to other teams and projects within 1-2 months. For such a policy to work, it needs to be easy to work in unfamiliar codebases. I can't speak for Java, but it's much easier to drop into an unfamiliar golang codebase and be productive and not introduce bugs than it is to do that with NodeJS or Python.
I do exclusively golang work now but when I joined I was doing exclusively NodeJS. While the first two to three months with golang were a bit frustrating, I can't imagine writing a backend in NodeJS ever again. That said, I would still use NodeJS to build frontend developer tools, but that's about it.
But the old Uber app had hit its age limit. It was build on top of technology chosen for a small number of features (ex: a single global DI component, lack of typing, a small MVC hierarchy). So we either needed lots of large migrations or a rewrite. The incremental migrations required to fix these issues would have been extremely disruptive, they wouldn't have gotten us an entirely refreshed UI and they wouldn't have given us a number of other benefits.
So we decided to do a rewrite. We had lots of engineers that knew the issues to watch for from the first time we wrote the app. And a handful of us spent months researching/building different architectures, static analysis and tooling that would ensure the rewrites success. We weren't going to repeat the same mistakes twice.
On the very first day the app launched it was more reliable and performant than the version of our app that we had been maintaining for years.