There's a meta-answer, which is Google is shipping its org chart.
Google Cloud UI is one giant Angular app with components written by sub-teams across wildly disparate timezones, much less offices. Their ability to consolidate resources is poor. They came late-to-the-game on tooling up an infrastructure team to provide both standardized libraries and rigor on how the architecture is used. The duplication of component logic is a direct consequence of this, as those components are ending up in the codebase as a side-effect of different segments of code, worked on by different teams, probably in different offices, "reusing" the same component---but not really, since they might be skewed on the version they're depending on. It's DLL hell in Javascript client form, basically.
And the product as a whole is chasing feature parity, not speed of UI.
The simplest way to not end up like Google Cloud UI is to not try to build a whole-product cloud solution. The second simplest way, if you're Amazon and you've already gone that road, is to have different sub-parts of your mega-architecture be different "apps" (really, different websites), each of which need pull in only the pieces it cares about, and be willing to take a whole-page refresh when the user transitions from one page to another.
This is what I was thinking as well. Once you recognize Conway's Law and Sinofsky's "don't ship the org chart" quote, you start to see it a lot in large companies.
Want another great example? If you write iOS apps, you'll probably have worked with the App Store Connect website. That site is such a hodgepodge of slightly different UI paradigms that it could only have been written by multiple teams with differing goals and timelines.
I've come to the conclusion that you want to structure your org chart to deliver the structure of application / experience you ultimately want to provide.
This reminds me of the famous comic about org structures of various companies. [1] Perhaps this is why Steve Jobs liked to get his fingers in everything, to make sure everything flowed smoothly according to his vision.
I mean, I create SPA's where this just works for nearly every navigation element. With a proper "route-first" design, this is not that hard. Of course, it is a bit more work to perform url navigation even when merely opening a subview, but it's definitely worth it.
I share your annoyance at all websites who don't allow for this though.
And even then in the Google Cloud console I still feel that parts such as Stackdriver are, in fact, completely separate parts of the UI and not integrated into the bigger whole. Same for many other products.
Which begs the question, what problem are they solving with this “unification but actually not” approach? Couldn’t they just bite the bullet and give up on the unification and be done with it?
Phrased differently, what are the advantages of this unification and reuse of components, exactly?
The stackdriver acquisition was a big eye-opener for Google. Well, should have been. I don't know if they actually learned any lessons. ;)
In theory, they expected merging SD into the GCP UI to be straightforward, because they're both Angular. In practice... Angular is a framework for inter-component communciation, not an SDK. And it's not a profoundly opinionated framework---the way the two codebases use Angular is so wildly disjoint that a merging was basically impossible without a rewrite. They don't even use the same date-time libraries.
One does wonder why they don't give up on the unification model.
The problem is that single-entrance is very valuable for ease-of-discovery. But complete integration / unification is just too difficult for something already present since they may simply use a totally different tech stack. Re-writing may not be justified by ROI.
For those kind of "separate parts", I can easily mention a few: 1. Stackdriver (acquired). 2. Cloud Data fusion (acquired, formerly cask.io) 3. BigQuery (predate GCP) 4. DataPrep (partnership)
> And the product as a whole is chasing feature parity, not speed of UI.
I find it hard to believe GCP is not chasing the UX experience since they have actively focused on building arguably non-priority features like a fully functional terminal within the cloud UI.
They care more than zero, but about feature completeness more than speed. Keeping in mind that their leading competitor (AWS) leaned heavily on CLI, providing web frontends is seen as a competitive advantage.
But they're far more focused on spanning feature set than the speed of the result.
This comment makes little sense. AWS is even less uniform when it comes to tools, exactly because of its organic growth. This clearly has no impact on its success nor its features.
Google does have a problem with management and the org-chart, but not the way you think.
AWS has significant first-mover advantage, but in chasing that advantage, Google sees providing a UI as a distinguishing feature to the AWS exeprience.
But their focus is on spanning the feature-set, not making the resulting UI fast. And the feature set is incredibly broad.
GCP's interface is worse because it clearly prioritizes form over function. When I click a button in the AWS control panel, generally it works. When I click a button in the GCP control panel, there's a non-trivial chance it will result in an infinite loading screen or an ambiguous error.
I see it all over Google's products (with the exception of search). Gmail loads 50mb of assets these days, and is extremely sluggish. It shows you the search bar but if you try to type in it too soon it'll skip characters and start to chop. It's embarrassing. And I'm on an i9 with a gigabit connection. Imagine how horrific it is to a user in the third world.
disclaimer: i work in google cloud, but on the apps side.
One thing worth noting here is that google pretty famously has a monorepo and single-version policy. Meaning: while you may be right about the subteams/orgchart meta-issue, it's not actually shipping multiple versions of the same subcomponent. There's just one version.
and i should add that this constraint is one of the reasons why some products get discontinued. right now, I'm dealing with migrating a dependency that has some breaking changes in an old section of my codebase that nobody has touched in years. I have to change it, because the dependency is changing, and I cannot continue to depend on the earlier version.
Happily, it is a simple enough update (and frequently these changes are automated by whomever is actually changing the library). But when this is something that needs extensive reworking, the project might get turned down instead.
I would have thought that you could reasonably decouple concerns in order to fix it as well. Have every service expose a nice restful API, and then have one team responsible for the web interface but use those apis. Obviously, you need a way to require a reasonable performance out of the backing apis, but at least then you only have the one team to be concerned with how to build the front end and ensure that it works well.
I would've expected a shared design library that had all the standard widgets, and then each page / area of the UI to be implemented and managed by the individual teams.
The dependency version drift could be solved by forcing every part of the application to use the same version, though obviously this increases the complexity of each upgrade.
My understanding from following angular development was that prior to each angular release they effectively beta test it across Google's estate - I think this is partly why the upgrade process is so smooth, because it wouldn't be tenable otherwise. The same pattern could be applied to a shared design library
> And the product as a whole is chasing feature parity, not speed of UI.
I thought google was actively avoiding parity-chasing, opting to "do their own thing, which will be better" instead. Or have I just been drinking the kool-aid?
While they do have some initiatives that are unique, the Cloud org's goal is absolutely "Beat Amazon and Microsoft at the market-share game." Which means they need all the meat-and-potatoes features (storage, compute, short-lived functions, monitoring and analysis, permissions on all of the above).
Google Cloud UI is one giant Angular app with components written by sub-teams across wildly disparate timezones, much less offices. Their ability to consolidate resources is poor. They came late-to-the-game on tooling up an infrastructure team to provide both standardized libraries and rigor on how the architecture is used. The duplication of component logic is a direct consequence of this, as those components are ending up in the codebase as a side-effect of different segments of code, worked on by different teams, probably in different offices, "reusing" the same component---but not really, since they might be skewed on the version they're depending on. It's DLL hell in Javascript client form, basically.
And the product as a whole is chasing feature parity, not speed of UI.
The simplest way to not end up like Google Cloud UI is to not try to build a whole-product cloud solution. The second simplest way, if you're Amazon and you've already gone that road, is to have different sub-parts of your mega-architecture be different "apps" (really, different websites), each of which need pull in only the pieces it cares about, and be willing to take a whole-page refresh when the user transitions from one page to another.