Conway's Law • Hacker News Board

Re: Conway's Law

#51

Post by staz » Wed, Apr 18, 2018, 4:41 PM UTC

delecti wrote: post #42

staz wrote: post #18

Earlier quoted context omitted.

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?

Yep entirely separate instance. I have 6 different slacks tab open for work at the moment.

They also have mails, Skype, Yammer, Ms Team, and a few different conferencing system on top of that.

it's a mess. For example nearly each team have their own Bitbuck, gitlab instance, github org , gitlab org or whatever VSTS use

Re: Conway's Law

#52

Post by stoshe » Thu, Apr 19, 2018, 6:00 PM UTC

baddox wrote: post #14

sverhagen wrote: post #6

Earlier quoted context omitted.

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…

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.

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.

Re: Conway's Law

#53

Post by stoshe » Thu, Apr 19, 2018, 6:06 PM UTC

sz4kerto wrote: post #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, y…

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.