alex-mohr

Process is useful for raising the lowest deliveries quality, for making former-unknowns into knowns, and for preventing misaligned behavior when culture alone becomes insufficient.

If you have need for speed, a team that knows the space, and crucially a leader who can be trusted to depart from the usual process when that tradeoff better meets business needs, it can work really well. But also comes with increased risk.

And you could write a similar blog post about why Google "failed" at AI productization (at least as of a year ago). For some of the same and some completely different reasons.

  - two competing orgs via Brain and DeepMind.

  - members of those orgs were promoted based on ...?  Whatever it was, something not developing consumer or enterprise products, and definitely not for cloud.

  - Nvidia is a Very Big Market Cap company based on selling AI accelerators.  Google sells USB Coral sticks.  And rents accelerators via Cloud.  But somehow those are not valued at Very Big Market Cap.

Of course, they're fixing some of those problems: brain and DeepMind merged and Gemini 2.5 pro is a very credible frontier model. But it's also a cautionary tale about unfettered research focus insufficiently grounded in customer focus.

The code in question reminds me a lot of my favorite Kubernetes bug:

  if (request.authenticationData) {
    ok := validate(etc);
    if (!ok) {
      return authenticationFailure;
    }
  }

Turns out the same meme spans decades.

As far as I could tell, its main goal was to have fun writing an OS. At that, it seems to have succeeded for a number of the people involved?

In terms of impact or business case, I'm missing what the end goal for the company or execs involved is. It's not re-writing user-space components of AOSP, because that's all Java or Kotlin. Maybe it's a super-longterm super-expensive effort to replace Linux underlying Android with Fuchia? Or for ChromeOS? Again, seems like a weird motivation to justify such a huge investment in both the team building it and a later migration effort to use it. But what else?

Clearly the next step after building your own CPU and SOC is to start Apple Foundry and become totally vertically integrated?

Also a myth for GCE.

From a technical perspective, App Engine and Compute Engine were built on top of internal infrastructure (borg), but did not expose borg directly. And there were a number of interesting mismatches between the semantics that customers expected of VMs and what borg offered to its containers that eventually resulted in dedicated borg clusters with different configs for cloud. And some retrospectives on whether building on borg was a better option than going bare metal directly.

Org-wise, the App Engine team was first and not part of the internal-focused Technical Infrastructure teams. GCS came next, and it too was not part of the canonical storage org. Then GCE, which was only possible because it was either written off or at least tolerated as an experiment by most, with a few key people providing behind-the-scenes support to make it happen -- especially in networking. It likely also helped that GAE was in SF and the rest of GCP in Seattle/Kirkland initially, so geo provided some insulation too.

The dominant perspective internally was that Google's technical infrastructure was its secret sauce, so why would they give it away to others? It took a long time to change that.

[Disclosure/source: I was on GCE and helped get it launched.]

If Netflix were working correctly and could handle the load, you'd absolutely be correct.

But it does seem the capacity of a hybrid system of Netflix servers plus P2P would be strictly greater than either alone? It's not an XOR.

And note that in this case of "live" streaming, it still has a few seconds of buffer, which gives a bandwidth-delay product of a few MB. That's plenty to have non-stale blocks and do torrent-style sharing.

J. Shallit (2003). "What this country needs is an 18c piece" (PDF). Mathematical Intelligencer. 25 (2): 20–23.

Willow appears closer to a "Protocol Construction Kit" than a protocol itself.

As a construction kit, it has value for people who want to make protocols where they'll control both ends, but don't have to re-implement basic table stakes.

I get that, but IMO it's not an issue.

On one shard you can't use more than base CPU, so there's no advantage to a subscription there.

Other optional shards are almost entirely people who subscribe. Do that too if you decide to, or ignore them.