4 ms·

"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." I'd say th

"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.

sverhagen 9y ago
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.
- sz4kerto 9y ago
  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.)
- baddox 9y ago
  Conway’s law doesn’t directly claim anything about the quality or effectiveness of the resulting system, but I suspect a corollary would also apply: that the effectiveness of a system is limited by the effectiveness of the communication structure of the organization that develops it.
  - stoshe 9y ago
    Conway's law doesn't make those claims, but this has been tested by researchers and industry giants (a Microsoft team published a paper on this a part of a Vista retrospective) and those papers do make such claims.
KevanM 9y ago
What if the communication structures are poorly designed and you are building a system on top of an organisation that is struggling to communicate effectively? The project leadership might hope that building a new system will be able change the communication problem. This suggests that it will only compound the problem.
- dx034 9y ago
  If the company knows that communication structures are poorly designed, the first priority should be to fix those. Fixing those first will probably have a higher impact on productivity.
stoshe 9y ago
I think the flaw here is that what works today may not work tomorrow and in many situations, it is easy to see where those breaking points will arise. Take your team sitting in one room building a monolith. Unless the software is intended to always be smaller and targeted, or the software fails in the market, that team will eventually scale and no longer fit in this room, and now you've got a monolithic application that can't be effectively maintained and enhanced by the organization. There is value in designing your system for the organization that will own it, but there is also a value in designing your organization for the system you wish to develop. Experience and published research have shown time and time again that whey you try to fight Conway's law, you will lose, so one or the other will have to give. For long-lived applications, you'll find more success if you can alter the organizational structure to fit the system.

sverhagen 9y ago

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.

sz4kerto 9y ago
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.)
baddox 9y ago
Conway’s law doesn’t directly claim anything about the quality or effectiveness of the resulting system, but I suspect a corollary would also apply: that the effectiveness of a system is limited by the effectiveness of the communication structure of the organization that develops it.
- stoshe 9y ago
  Conway's law doesn't make those claims, but this has been tested by researchers and industry giants (a Microsoft team published a paper on this a part of a Vista retrospective) and those papers do make such claims.

KevanM 9y ago

What if the communication structures are poorly designed and you are building a system on top of an organisation that is struggling to communicate effectively? The project leadership might hope that building a new system will be able change the communication problem. This suggests that it will only compound the problem.

dx034 9y ago
If the company knows that communication structures are poorly designed, the first priority should be to fix those. Fixing those first will probably have a higher impact on productivity.

stoshe 9y ago

I think the flaw here is that what works today may not work tomorrow and in many situations, it is easy to see where those breaking points will arise. Take your team sitting in one room building a monolith. Unless the software is intended to always be smaller and targeted, or the software fails in the market, that team will eventually scale and no longer fit in this room, and now you've got a monolithic application that can't be effectively maintained and enhanced by the organization. There is value in designing your system for the organization that will own it, but there is also a value in designing your organization for the system you wish to develop. Experience and published research have shown time and time again that whey you try to fight Conway's law, you will lose, so one or the other will have to give. For long-lived applications, you'll find more success if you can alter the organizational structure to fit the system.