> The engineers in charge of these systems have been "at odds," which has created friction, according to The Information.<p>> Uber’s chief technology officer, Thuan Pham, later wrote to his staff that the mistake “reflects an amateurism with our overall engineering organization, its culture, its processes, and its operation.”<p>This makes it sound as if the two engineers in charge of the Node.js and Python systems are bickering over which technology stack is better and refuse to compromise. I get there is worry about career progression if your backend option loses, the glory of being <i>the</i> engineer in charge of the entire backend of Uber, and the different specs of different technologies. But to hold the entire company hostage seems like it would be a career-ending move to me, regardless of sides. Then again, I am not in management.
Some serious link bait in that article title - sounds like they've got issues but they are working through it. The article ends by pointing out that New Years Eve went off without a hitch.
"The company's engineering staff has grown to 1,200 — a quarter of Uber's workforce — from just 400 people."<p><i>1200?</i> I'd be very interested to know what they're all doing. Not saying that what the company is doing is easy on that scale, but it's hard to see how throwing <i>a thousand people</i> at the problem can be an effective solution. Unless many of them are working on new products? But Uber seems pretty young to be investing that much in R&D.
What benefits would they see/get from using their own co-located servers instead of using VMs on a cloud provider?<p>For a fast-growing business, it would seem a huge win to not have to worry about physically scaling your infrastructure. And I can't imagine that their infrastructure size is so large (they're not, for example, indexing the internet) that they would get a huge cost savings from using their own hardware.<p>But certainly, I must be missing something?
"reflected an amateurism with our overall engineering organization, its culture, its processes, and its operation.”<p>That is not going to get the engineers on your side to solve the problem. Instead it will create even more friction between managers and engineers.
"setting up servers in a new data center on Halloween"<p>That kind of problem seems remarkably common - the end of months and years can be peak times for businesses but it's also the kind of date that people pick for their project milestones ("we'll have the servers in by the end of the year").
Yeah, this article is in "Business Insider" rather than "Tech Insider." Ya can tell by reading it. The real WTF is having that many developers without a solid ops team to match. At least they can charge extra for peak loads, which many of us cannot do.