Conway's Law
en.wikipedia.org
Conway's Law
1–10 of 53 posts
Re: Conway's Law
#2"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."
I'd say that organizations are not just constrained to do that -- they should. When you design systems and infrastructure, keep in mind that systems and solutions are under evolutionary pressure, and engineers have to change it all the time. When optimizing for change, you need to optimize for teams and interactions.
If the whole team is sitting in the same room, then there's nothing wrong with a monolithic app and shouting to others that 'hey, does anyone have a problem if I release the latest master branch?'; or it's also fine to have a QA server that the team is using. At a remote company, it's much more important to be able to test subsystems in isolation or even without internet access, automated integration tests are more useful and important.
And so on.
Re: Conway's Law
#3Has this appeared on here because it was discussed on This Week in Tech (TWiT) ?
Re: Conway's Law
#4Conway'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 the link) that shows that the number of bugs introduced into system is highly correlated to the number of lines of communication between the people or teams that write it. Add another team and that number potentially rises exponentially. Conway's Law is the scaffold on which all these understandings hang.
Re: Conway's Law
#5Conway's law can explain a lot about current Facebook privacy debacle.
Re: Conway's Law
#6"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." I'd say that organizations are not just constrained to do that -- they should. When you design systems and infrastructure, keep in mind that systems and solutions are under evolutionary pressure, and engineers have to change it all the time. When optimizing for change, y…
Probably you're just oversimplifying for brevity or something. But I've worked at plenty of projects where the team was sitting together, the product was a monolith, and it was still a problem. Coordination becomes easier, sitting together, but the need to coordinate, or the level with which people start "stepping on each other's toes" (code-wise) isn't reduced by it. I'm not saying all monoliths are bad, or that you would never want one, but when it becomes a problem, there's little consolation in sitting together.
Re: Conway's Law
#7Conway's law can explain a lot about current Facebook privacy debacle.
It does. Move fast and break things. Thye have broken a lot of things.
Re: Conway's Law
#8"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." I'd say that organizations are not just constrained to do that -- they should. When you design systems and infrastructure, keep in mind that systems and solutions are under evolutionary pressure, and engineers have to change it all the time. When optimizing for change, y…
Probably you're just oversimplifying for brevity or something. But I've worked at plenty of projects where the team was sitting together, the product was a monolith, and it was still a problem. Coordination becomes easier, sitting together, but the need to coordinate, or the level with which people start "stepping on each other's toes" (code-wise) isn't reduced by it. I'm not saying all monoliths are bad, or that you…
Of course I'm not trying to provide the ultimate recipe to big IR problems on HN in 10 lines of text written on my phone :)
Just wanted to say that communication patterns and specifically communication overhead can and should be reflected in modularization of software. If two people can talk to each other very easily (because they're sitting near each other) then maybe (!) separating their code through e.g. APIs doesn't need to be that strict compared to teams who never talk to each other in person. These are not hard rules, but good guidelines. (Modularization isn't for free, so there's always a balance.)
Re: Conway's Law
#9Conway'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…
> Conway's Law validates a decision to move to a service-oriented and/or microservice architecture. Each service ~= a business unit or department.
I wouldn't say Conway's Law validates a decision to move to an SOA, so much as further enshrines it in code. There is something to be said for forcing different business units or departments to work together.
Re: Conway's Law
#10Conway'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…
> Conway's Law validates a decision to move to a service-oriented and/or microservice architecture. Each service ~= a business unit or department.
Organising the business units around the desired deployables is also know as "the Inverse Conway Maneuver"
https://www.thoughtworks.com/radar/techniques/inverse-conway...
http://betica.com/blog/2016/06/17/transform-your-organizatio...