TIL Conway's Law isn't "Life Finds a Way"
Conway's Law
41–50 of 53 posts
Re: Conway's Law
#42What do you build when everyone talks to each other over Slack?
depends on how they talk on slack and who talks to who. The company I'm working with at the moment has separate slack per team with each time being ~5 persons and then some people from other team on each slack who pass message.... the communication is not great and the collaboration between services isn't either
Entirely separate Slack instances? Not just separate channels?
Re: Conway's Law
#43I feel old when these kind of Wikipedia pages make it to the front page and I was assuming that it was known and obvious for everyone.
Yes. When speaking and writing, I constantly struggle with the fact that a lot of things that are eye-rollingly last year's or even last decade's news for some are eye-opening new concepts for others. It's easy to assume that what's almost cliche in your specific circle is as well known everywhere.
Its almost like we live in some sort of 'forever september '
Re: Conway's Law
#44the Twitter offices must be a special kind of hell. could you imagine twitter in real life?
Re: Conway's Law
#45Some previous discussions over the years: https://hn.algolia.com/?query=Conway%27s%20Law%20points%3E3&...
Re: Conway's Law
#46Have anyone deep dived into this ? I'm interested in learning more. What is the most common communication structures and what designs does those correspond to ?
Re: Conway's Law
#47I always suspected this could be applied to civilization and the human mind as well - that the structure of society has some similarities to the structure of our brains.
Re: Conway's Law
#48Conway's Law validates a decision to move to a service-oriented and/or microservice architecture. Each service ~= a business unit or department. Even better is that such an architecture requires (or at least greatly benefits from) specifying precisely the communication between the interacting parts in the form of interfaces. IIRC there is a study that Steve McConnell mentions in one of his books (sorry, I can't find…
Not necessarily. It depends how you define "service". There are two interpretations of Conway's Law: 1) orgs "just" end up making software partitioned like the org structure due to human nature, or 2) orgs should partition software like the org structure.
My experience heavily leans to #2. If your software doesn't "fit" the org, friction happens. For example, if you try to share a common service but there is nobody with sufficient power and staff to manage and coordinate changes in that service, then it's not clear who to blame when bleep happens.
A technician can make a shared service, but then the technician is left holding the responsibility bag when there are conflicts or complaints among the shared service users. Managers don't want to let "lowly" techies control such decisions. Almost nobody is used to that.
Either create a formal org sub-structure with a sufficiently ranked manager(s) to coordinate the shared service, or split it and live with redundancy.
Re: Conway's Law
#49Has this appeared on here because it was discussed on This Week in Tech (TWiT) ?
Yip, that is where I heard about it- found it very interesting and applicable.
Re: Conway's Law
#50I am aware of this theoretical law but never really considered it. I suppose this could explain why I encountered such push back against a distributed SOA architecture on commodity hardware at a large organization that was built around centralized systems using mainframes. Ultimately after three years of justifying and re-justifying the decisions I made for which they explicitly hired me for I moved on. It was abunda…
> The expectation was to follow this ridiculously verbose chain of command > whereby response to even a simple question could take days or even weeks. oh so they already did SOA
I can't get a clear meaning of "SOA". Data and processes have been shared for many decades. Stored procedures are a common example of such before the Web era. Shoving stuff into JSON doesn't necessarily make it better, and often creates more maintenance work. Do things for a clear reason, not because it's in style.