We're not using zoom, but google meet - but yes, these happen completely online now.
I find that people that are doing interesting stuff often _want_ to talk about it. However, a big part of Shopify culture is "do things, tell people" - it is definitely encouraged to spend time spreading context.
It's not directly part of any rewards framework, but one metric that goes into promotions is the area of impact. By giving a talk to the guild, you can have impact on a group that's larger than your team, potentially the whole organization. It counts.
But another reward is the positive feedback, interesting discussions and new connections that you make through this.
> When I left, we were up to a few dozen components, and the number was climbing rapidly.
I should have included this in the blog post: The number of components _needs_ to be kept small. Shopify's main monolith is 2.8 million lines of code in 37 components, and I'd actually like to get that number _down_.
I like to compare this to the main navigation that we present to our merchants. It's useful if it has 8 entries. It's not useful if it has 400.
In a way, components are the main navigation to our code base. A developer should be able to look at what's in our "components" folder and get a general impression of what the system's capabilities are.
It's all tradeoffs. You get a stronger boundary, but you also get a distributed system.
Also, the first try of drawing boundaries will always be varying degrees of wrong. If you have very strong boundaries at this stage, iterating on them, moving responsibilities around, can be harder.
Also, with the right tooling it's definitely possible to harden monolith internal boundaries to a comparable level.
I can see though how many smaller companies would not be in a position to build that tooling.
Anyway... there is no either / or here, as I've explained in another comment. What if you have components within a monolith, but each component has its own database, for example? What if test suites are completely isolated, so that tests for component A can not access code in component B?
You can get pretty strong boundaries with a few comparably simple tricks.
- same database
- same runtime
- same deployment
- same repository
That said, I don't think this is an either/or. It's a spectrum. you can have components within the same runtime and repository that have separate databases, or components that are using the same database but live in separate repos, etc.
From one monolithic app towards fully separated microservices is a spectrum, and I think developers should be enabled to move freely around that spectrum.
Ours kind of organically grew over time, but as I've been keeping it alive for the last few years I have a pretty good idea of how I would start it fresh.
You probably have some people in the company who either know much more about architecture than others, or are working on projects that are more interesting in terms of architecture. Find one of them, convince them to give a 15 min talk.
Announce the talk widely within the company, tell people to come to the new "architecture guild" slack channel you created to get the details / invites.
Schedule an hour to give plenty of time for discussions after the talk.
It's certainly related. In very general terms, I would say splitting a Rails app into multiple engines is the same pattern as umbrella applications.
However, there are more interesting specifics here about things like all engines sharing a database, but having exclusive ownership of tables, as well as splitting HTTP routing over multiple engines etc.
The answer to that question could probably fill another blog post :D
Long story short, Rails and dependency inversion equals lots of friction. The whole framework is built on the assumption that it's OK to access everything from everywhere, and over the years we've built lots of tooling on top of those assumptions.
We also have a GraphQL implementation that is pretty closely coupled to the active record layer and _really_ wants to reach into all the components directly.
All of those problems can be overcome, but this is definitely an area where we have to working against "established" Rails culture, and our own assumptions from the past.
Very interesting discussion, although there already are solutions to some of these problems in other type systems.
Erlang also has optional type annotations via the dialyzer tool and all types are by default non-nullable.
Generally I think that the dart language implementors should try harder not to copy language design fails from Java / C++, like null-pointers or half-baked enumeration types.
I agree, there will be lots of low hanging fruits. But I guess GOG is playtesting every single one of them so it could take a while. The linux testing team is probably smaller than the windows and mac teams.