News for hackers. Stuff that matters.
Re:Building Uber’s Go Monorepo with Bazel by schoolornot on Thursday May 14, 2020 @11:36AM (#23180805)
- nothing wrong with NIH syndrome if you have the means and resources to refine existing ideas and rebuild them with scale in mind

- uber is a 50 billion dollar company and they have to de-risk themselves by owning entire stacks, top to bottom. if it means re-creating something from scratch... who cares, they have billions.

Re:Building Uber’s Go Monorepo with Bazel by harikb on Thursday May 14, 2020 @11:48AM (#23180946)
While I understand the point that they have money to burn, there are better ways to spend that money. Some items like “databases” are core to their SLA that it makes sense to invest. Build, source code management, etc are not “critical to de-risk”. It is not like Microsoft will one day refuse to sell them GitHub enterprise or GitHub actions because some division of Microsoft is competing with them.
Re:Building Uber’s Go Monorepo with Bazel by klodolph on Thursday May 14, 2020 @12:00PM (#23181113)
That’s just apologia for NIH syndrome. It’s fine to reinvent software if that serves your goals. It’s short-sighted to reinvent software without due consideration for whether off-the-shelf solutions work. That’s not de-risking, that’s adding risk and slowing development. You see it happen at companies like that and usually it’s a sign that there’s something wrong with the culture, incentives, and the way that promotions work.

My take on it is that the engineers want to make complicated solutions to hard problems to justify their salaries and get promoted, and that managers encourage that behavior so they can defend their headcount. I’m not accusing any of these people of acting in bad faith here—nobody’s reinventing tech to sabotage the company, it’s just that the system encourages this kind of behavior.

This problem is not unique to Uber, you’ll see similar things happen across the industry to different degrees.

Re:Building Uber’s Go Monorepo with Bazel by jeffbee on Thursday May 14, 2020 @12:27PM (#23181502)
Well, the "due consideration" needs to duly consider the actual costs and benefits of the off-the-shelf software, not make the kind of unsupported blanket claims about its obvious superiority, like you just did. Every off-the-shelf program has maintenance costs, flaws, and weak fitness for purpose. You just made a sweeping and italicized claim that all off-the-shelf software is both less risky and faster to develop than house-made software. That's a dangerous philosophy and probably isn't true for every organization and application.
Re:Building Uber’s Go Monorepo with Bazel by klodolph on Thursday May 14, 2020 @01:33PM (#23182590)
> …not make the kind of unsupported blanket claims about its obvious superiority, like you just did…

Not what I said. Let’s move on.

> That's a dangerous philosophy…

Go pick a fight with someone else.

Re:Building Uber’s Go Monorepo with Bazel by nickv on Thursday May 14, 2020 @11:40AM (#23180845)
Or, at that point, you use industry standard solutions and hire the best subject matter experts on that solution. Like, for example, using Cockroach DB and hire one of the core committers cause you're big enough. It's what MSFT did with things like the Python extension for VSCode and DBOX did by hiring Guido since they're a Python shop.

I still shake my head whenever I hear about how Uber built an entire Slack clone for "Uber-scale".