[californical]

Yeah I think the main idea is that people who like clean organization, boundaries, tidiness, clear responsibilities, etc, will tend to congregate together. And their organizations will be that way, and so will the things they create together.

People who like experimentation, chaos, prototyping, flat hierarchies, etc, will also tend to congregate together, and the systems that they build will also have those values.

Same for lots of different qualities. It isn’t A->B or B->A, it’s more like A<->B<->C.

[xpe]

I like the idea of Conway's Law, but I also like to be critical of vague theories. Maybe it is asking too much, but I don't see people using it in a testable way. This isn't just selection or survivorship bias; I think the "law" itself is too vague to admit a true experiment, even an associative one. I'm happy to be shown to be wrong... or that I'm missing the point.

Another way of making this point is: what could make Conway's Law totally wrong? What evidence could do that? It seems like shifting sands -- there is always something that fits the "pattern"; the problem is the pattern is not defined a priori: it feels like getting your organization's palm read.

[californical]

Totally agree. I guess I just like it as a concept because it’s almost a tautology.

Organized people are organized.

People who value short-term experiments will make short-term experiments.

The only part that is palm-reader level is the translation across contexts. And I agree that it’s a terrible law, but probably a decent rule of thumb, that someone who is tidy in one area of their life is likely tidy in others. But yeah, we shouldn’t really look into it any more than that.

It’s like other vague assumptions that our brain makes. Probably correct to some degree sometimes, but not a hard rule by any means.

[gwright]

I never took it to be about organization vs chaos.

For example, if a team is responsible for two modules of an application they are less likely to create an API because the modules can communicate directly inside the application (i.e. monolith)

If the same two modules are cared for by separate teams, then maybe they end up being two separate API services.

It both cases there is organization, just different types of organization.