4 ms·

> there is no need to have the microservices built along Conways Law This is a misunderstanding of Conway's Law. Your code _will_ reflect the structure of your

by zbobet2012 4y ago

> there is no need to have the microservices built along Conways Law This is a misunderstanding of Conway's Law. Your code _will_ reflect the structure of your organization. If you use microservices so will their architecture. If you use modules, so will the modules. If you want a specific architecture, have your organization reflect the modules/microservices defined in that architecture.

zeroonetwothree 4y ago
Exactly. Conway's Law is descriptive not prescriptive!
- bradwood 4y ago
  Quite. And many people still seem to confuse this. The way to exploit Conway's law is not to do anything _technical_ but rather to do something _organisational_. The "Reverse Conway Manoeuvre" is the term, IIRC, for this. Rather than trying to "build something along the lines of Conway's law" (which doesn't really make sense) -- one should determine a desired architecture and then set up the _organisation_ and teams to mirror that.
lifeisstillgood 4y ago
But, I am trying to feel my way towards the idea that that was true when managers arranged systems for workers to follow, and then we came along to automate the current process. But if we have a system where the workers are the CPUs, then the people doing the managing are the coders. The point ebing is that if workers are CPUs and coders are managers, then why worry about how the managers of the coders are arranged. Get rid of that management layer. Conway is not implying the financiers of the organisation affect the architecture. This basically means that the microservices a company is built out of should more readily align to the realities of the business model. And instead of shuffling organisations around it would behove executives to look at the microservices. One can more easily measure orders transferred, etc, if the boundaries are clearer. Plus conway is just a ... neat idea, not a bound fate. There is a caveat with the architecture reflecting the organisation of the software teams, but that usually follows the other to-be-automated structure as well.
- zbobet2012 4y ago
  Managers arranging work is _not_ why Conway's law is true though. I think it behooves one to look at the actual text of the "law": > Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. It doesn't matter WHO defines or does the work (the coders themselves in a team or the manager). It matters how communication is arranged. And communication naturally aligns itself along organizational and team boundaries. When a group/person/whatever writes an API they are MOSTLY writing a document for other human beings. That is an act of communication. If you meet with someone everyday in a stand-up you're likely to put a less structured API between yourselves than if you meet with someone once a month, or once a year. You're also going to create a finer grained subdivision of the API for them as you're likely working on closely related posts of the problem. Organization creates communication, and communication creates architecture. Therefore organization creates architecture. > Plus conway is just a ... neat idea, not a bound fate It is in fact bound fate. Code is written to communicate with others. People come together, they decide to solve a problem. They divide up that problem and create functions (an API), objects (an API), modules (an API), and services/microservices (an API). At each later they've written something that communicates with others. The structure of that code reflects the necessary communication to the other parties for their part of the problem. This the code is structured following the lines of communication in the organization. Organization is how we structure communication (that's it's primary point) and thus organization = architecture + some wiggle room for communication paths defined outside that (say a SAFE feature team).
  - marcosdumay 4y ago
    > It matters how communication is arranged. Just to add it here, how evaluations and goals are set matter too. Those tend to be even more constrained by the formal organization than communication.
- 8note 4y ago
  The systems are not only organized on the programmers managers, but their managers too, all the way up the chain.

zeroonetwothree 4y ago

Exactly. Conway's Law is descriptive not prescriptive!

bradwood 4y ago
Quite. And many people still seem to confuse this. The way to exploit Conway's law is not to do anything _technical_ but rather to do something _organisational_. The "Reverse Conway Manoeuvre" is the term, IIRC, for this. Rather than trying to "build something along the lines of Conway's law" (which doesn't really make sense) -- one should determine a desired architecture and then set up the _organisation_ and teams to mirror that.

lifeisstillgood 4y ago

But, I am trying to feel my way towards the idea that that was true when managers arranged systems for workers to follow, and then we came along to automate the current process. But if we have a system where the workers are the CPUs, then the people doing the managing are the coders. The point ebing is that if workers are CPUs and coders are managers, then why worry about how the managers of the coders are arranged. Get rid of that management layer. Conway is not implying the financiers of the organisation affect the architecture. This basically means that the microservices a company is built out of should more readily align to the realities of the business model. And instead of shuffling organisations around it would behove executives to look at the microservices. One can more easily measure orders transferred, etc, if the boundaries are clearer. Plus conway is just a ... neat idea, not a bound fate. There is a caveat with the architecture reflecting the organisation of the software teams, but that usually follows the other to-be-automated structure as well.

zbobet2012 4y ago
Managers arranging work is _not_ why Conway's law is true though. I think it behooves one to look at the actual text of the "law": > Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. It doesn't matter WHO defines or does the work (the coders themselves in a team or the manager). It matters how communication is arranged. And communication naturally aligns itself along organizational and team boundaries. When a group/person/whatever writes an API they are MOSTLY writing a document for other human beings. That is an act of communication. If you meet with someone everyday in a stand-up you're likely to put a less structured API between yourselves than if you meet with someone once a month, or once a year. You're also going to create a finer grained subdivision of the API for them as you're likely working on closely related posts of the problem. Organization creates communication, and communication creates architecture. Therefore organization creates architecture. > Plus conway is just a ... neat idea, not a bound fate It is in fact bound fate. Code is written to communicate with others. People come together, they decide to solve a problem. They divide up that problem and create functions (an API), objects (an API), modules (an API), and services/microservices (an API). At each later they've written something that communicates with others. The structure of that code reflects the necessary communication to the other parties for their part of the problem. This the code is structured following the lines of communication in the organization. Organization is how we structure communication (that's it's primary point) and thus organization = architecture + some wiggle room for communication paths defined outside that (say a SAFE feature team).
- marcosdumay 4y ago
  > It matters how communication is arranged. Just to add it here, how evaluations and goals are set matter too. Those tend to be even more constrained by the formal organization than communication.
8note 4y ago
The systems are not only organized on the programmers managers, but their managers too, all the way up the chain.