First of all, it's not like most engineers at Google are working on Bigtable or Borg, with a "very simple interface and tons of hidden internal complexity". Plenty of them are working on normal consumer-facing products, the "software with a simple core and lots of customer visible features that are incrementally useful", although maybe that's not the hype people want to believe.
But either way -- he insists "companies like Google write revolutionary software which has never been written before, and which doesn’t work until complex subcomponents are written." But putting aside the "revolutionary" hype, there's no reason subcomponents can't have agile philosophies applied.
A big part of agile is ensuring developers actually understand the requirements (consensus via point estimation), seek to define requirements where they're suddenly discovered to be vague/undefined, and have frequent check-ins to demonstrate that their software is making progress towards those requirements and raising any potential blockers early on, and not accidentally going down a rabbit hole of building the wrong thing (despite best intentions) for weeks at a time which nobody notices until too late, and the project is delayed by months.
That's just as important for a subcomponent of a subcomponent, as it is for a service dashboard. To assume agile is only for "consumer-facing" software is a deep and fundamental misunderstanding.
This is true. I'm a swe at Google. My team uses scrum methodology, and is responsible for a customer facing but thoroughly "normal" product. My work doesn't involve building heretofore unknown planet scale computational resources. It's just a normal product where I'm a full stack dev.
I'm sure there's ways we can improve our canonical agile-ness, but it's not lip service. We set quarterly goals sure, but they can change if situations change and the goals themselves are usually data-driven (based on prior quarters a/b testing and other research done by our UX team). We also have strong product and project managers, who own a lot of the scrum meta-work.
So, I guess #notallgooglers (which for context is an ironic, kind of self deprecating response here). There's tens of thousands of engineers at G. Some teams are agile, some aren't.
This Qoura post is typical pro-Google propaganda. Things at current Google are far from described: modern Google is deep bureaucratic hierarchical organization.
First of all, it's not like most engineers at Google are working on Bigtable or Borg, with a "very simple interface and tons of hidden internal complexity".
I would say that most engineers are working on something like that. Those two examples are from google cloud/technical infrastructure, but other products such as search and ads have tremendous complexity behind them.
I feel like this hubris is why almost every google product I use is riddled with horrible bugs. The cursor move functionality on Gmail for iOS has been broken for TWO YEARS. It’s also why the tensorflow API is a horribly over-engineered abomination when Pytorch is almost at feature and performance parity with something exponentially simpler and more consistent/elegant. That “biggest baddest solution” culture makes sense for Bigtable; it’s god-awful for anything remotely customer facing.
> Plenty of them are working on normal consumer-facing products, the "software with a simple core and lots of customer visible features that are incrementally useful", although maybe that's not the hype people want to believe.
Honestly, it seems a bit elitist to me.
I work at a company that pioneered SOA for both technical and organizational flexibility reasons and I'd say it's worked out pretty well for us!
First of all, it's not like most engineers at Google are working on Bigtable or Borg, with a "very simple interface and tons of hidden internal complexity". Plenty of them are working on normal consumer-facing products, the "software with a simple core and lots of customer visible features that are incrementally useful", although maybe that's not the hype people want to believe.
But either way -- he insists "companies like Google write revolutionary software which has never been written before, and which doesn’t work until complex subcomponents are written." But putting aside the "revolutionary" hype, there's no reason subcomponents can't have agile philosophies applied.
A big part of agile is ensuring developers actually understand the requirements (consensus via point estimation), seek to define requirements where they're suddenly discovered to be vague/undefined, and have frequent check-ins to demonstrate that their software is making progress towards those requirements and raising any potential blockers early on, and not accidentally going down a rabbit hole of building the wrong thing (despite best intentions) for weeks at a time which nobody notices until too late, and the project is delayed by months.
That's just as important for a subcomponent of a subcomponent, as it is for a service dashboard. To assume agile is only for "consumer-facing" software is a deep and fundamental misunderstanding.