Conway's Laws isn't a law, it's just an interesting thought experiment. Organization and architecture bidirectionally effect each other, but not directly, and not completely. I hate how current discourse invokes these different "Laws" as if they are physical properties of the universe. I've worked at places with a strong, hierarchical organization that created a wonderful set of "micro" services, and I've worked at places with a chaotic environment that developed monoliths.

There are shitty hierarchies and shitty flat organizations, just like there are shitty monoliths and shitty microservices.

Sorry if you actually agree with this more nuanced view, it's just that I've seen Conway's "Law" invoked more than once in this discussion and it drives me bonkers. I get the same way when someone ("Medium Developers" I call them, more than green but less than seasoned who swallow everything the read on Medium as gospel and run around quoting it zealously) quoted liskov substitution principle at me as if it was one of Newton's Laws.

Conway's Law is a physical law in the same sense as Murphy's Law.

It's also obviously true. The organization builds the architecture. The architecture either helps or hinders the organization. The organization builds a new architecture. There's no indirect connection here. If you've seen hierarchical organizations implement microservices, it's because that organization's complement was a microservices architecture. And likewise for a chaotic organization.

--well, sidetrack: Aren't strongly hierarchical organizations the best suited for microservices? With all the strongly divided responsibilities and whatnot?

> Conway's Law is a physical law in the same sense as Murphy's Law. It's also obviously true.

It's like a tautology: "In logic, a tautology is a formula or assertion that is true in every possible interpretation."

Thank you for everything you said. The reality is more nuanced and depends on the specifics. The "law" being zealously cited here isn't a rule. Nor is the thought an approach is wrong if a big organization failed at it.

2 pizza team?

Well finally I might get my own microservice after all.

This metric is also unsuitable for Europe, where generally pizzas are individual.

You can get party pizzas but in that case the two pizza team might be a bit large.

Well.. just consider every "microservice" a separate company, exposing its own product/service. Also think about all the overhead that comes with it - product managers, finance, recruitment etc.

See Coase and the "Theory of the Firm": https://en.wikipedia.org/wiki/Theory_of_the_firm

Occasionally companies actually do this by fragmenting divisions into separate companies, such as outsourcing IT. It has a very broad range of outcomes, from saving to destroying the business.

So like monoliths vs microservices it's probably a balance between the two (leaning heavily in one direction).

I've never understood why it needs to be either/or. Is it really that difficult to support a microservice deployment that only represents 50% or even 20-25% of the org/project?

If all the services that the microservice needs are also services behind an API, what's the overhead? Something like:

hire("developer", 10, "10x).addToPayroll().office("openplan", "wfh").enforceHRPolicies()

Is all you need

The best thing about this is that you can keep everything in change control and just rollback whenever you need to, or spin up new companies at will.

Absolutely, you probably can't succeed with microservices without selforganizing teams. You just get more hot potatoes to drop