4 ms·
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 mono
by 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 agoOf 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 agoConway’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 agoConway'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.