
Conway's Law - brudgers
http://www.melconway.com/Home/Conways_Law.html
======
kabdib
Oh yeah. I've worked in on a couple of products where there was a "client
floor" and a "server floor" and the two groups would integrate their stuff
every three or four months . . . or five, or six. Didn't work all that well.

At the last place I remarked that a better seating arrangement for the project
would have been to place everyone at random, and I wasn't kidding.

I really like the model of movable desks. An engineer and a finance person
need to sit together for a while? Just find a spot, or make room where one of
the parties happens to be. Oh, we need a designer, and a lawyer? That's easy.
Need to go find a spot where you can work alone for a couple of weeks? Done.
Of course, this sends shivers up the spines of people who feel the need to
exert control in the workplace.

You're still up against Dunbar's number. At some point you can't keep everyone
in your head. Meatware doesn't scale well yet.

~~~
vitd
"Of course, this sends shivers up the spines of people who feel the need to
exert control in the workplace."

I'm not sure who you mean here. As an employee, I would dislike moving around
a lot as I like to, for example, have a picture of my wife on my desk, or have
a pair of headphones I leave at the desk so I don't have to lug them back and
forth between home and work. I also have some useful physical references I
keep around and have physical (paper) files I need to keep track of for my
job. Having to move all of those things or having them in a place other than
within arm's reach at my desk would make me less productive. If trying to
remain productive means "feeling the need to exert control in the workplace,"
then yeah, guilty as charged.

Other than that, I like the idea of mixing up who sits where, so long as it's
for relatively long periods of time. Weeks at least, preferably months. It
would be annoying to have to move every few days.

~~~
someperson
Grandparent comment is talking about 'control freak' management, not an
employee managing his personal desk space

------
quizotic
I'm sure it's willful blindness on my part, but in 30 years, I can't think of
a single example of a design I've helped create that was a reflection of the
organization's communication structure. I've built object databases,
distributed share-nothing databases, a sentiment extraction system, and a
mobile geo-locations application. Can anyone give a real world example of
Conway's law?

~~~
phamilton
Simple example:

You have two teams that work on different systems. A feature needs to be built
that crosses the two systems. Do you:

a) Build a temporary team with 2 developers from each team.

b) Create a spec and hand it to Team 1. Team 1 adds an API for Team 2 to
consume. Team 2 gets the API spec from Team 1 and integrates.

In situation (a), it's likely your solution will blur the line between system
1 and system 2. The solution will be very specific and implementation details
on each side will be blurred together influencing the result.

In situation (b), it's likely that the API on system 1 is more generic and
less coupled to the implementation details of system 2.

Situation (a) is generally faster to market. Situation (b) is generally easier
to maintain, but can be much, much slower.

A specific example I've seen recently is a web server written in C doing
string manipulation and a javascript client consuming data from this API.

If I'm working closely with the frontend developer, I'm going to say "How
about I send you the data raw, and you split on this sequence". Splitting in
javascript is much simpler than strtok_r and as a bonus I offload the
processing to the client. From a development standpoint, it takes 2 minutes to
coordinate.

If I'm not working with the frontend team, then I'm probably going to go
through the trouble of doing the string manipulation server side.

Does that make sense? (not the design itself, but as an explanation of how
communication influences design).

~~~
caminante
I didn't find that simple at all >_<. Your example works, though, I fear
you're getting way to granular for the application of Conway's Law, which
talks more to how applications map to departments/power structures.

edit: Thinking further, I think that for Conway's Law to apply, it isn't so
much about time/cost/complexity tradeoffs, but more about constraints due to
your org structure and communication. Conway's Law would be more acute if due
to some communication constraint in your company (e.g. regulatory, politics,
incompetence), you were forced to go with choice A or choice B (e.g.
information silo).

~~~
phamilton
Conway's law is all about communication structure. Abstractions and
constraints in communication influence abstraction and constraints in
software.

------
gizi
I find Eric Raymond's example for Conway's Law quite funny: _If you have four
groups working on a compiler, you 'll get a 4-pass compiler_.

~~~
mdpopescu
Counterexample that actually refers to Conway's Law in the comments :) The
63-phase compiler
[https://news.ycombinator.com/item?id=9289070](https://news.ycombinator.com/item?id=9289070)

------
rumcajz
This is one of the most important comupter science laws out there, yet, people
mostly treat it as a joke.

Anyway, the bottom line is that the teams should be built in such a way as to
reflect desired architecture of the project. If you fail to do that, the
project will end up with shitty architecture.

------
quizotic
I think this emperor has no clothes! Take distributed concensus protocols:
two-phase-commit (or RAFT et al). I have never worked in an organization that
adopted a 2PC communication protocol. The only real-world example I know is a
wedding ceremony: "Do you Jane, take Tarzan to be your ape-man? (Jane says 'I
do') And do you Tarzan, take Jane to be your swinging partner (Tarzan says
'Woo hoo!'). I now pronounce you husband and wife (because you've each locally
committed)" Can you imagine working in a place like that? And yet 2PC is part
of most database design.

Or take a design that consists of functional transformations of a sequence of
ASTs. What organizational communication structure is stateless? ("Don't tell
me you already told me that a minute ago! I refuse to remember anything you
say. ever. You want to tell me something, start from the beginning every time.
And furthermore, I refuse to talk to you at all unless we're given an entirely
new language in which to express our conclusions. Besides, you're nothing but
a monad to me") Ridiculous for human communication, but arguably essential for
large-scale distributed parallel computation.

Or take event-bubbling, or model-view-controller. Does any organizational
communication system use those in anything other than a once-in-a-blue-moon,
accidental way?

------
tunesmith
I've actually been wondering about this in regard to microservices. As people
switch from monolithic architecture (where one war or package might have both
frontend and backend) to microservice architecture, are you finding it useful
and necessary to change your team structures? A lot of place have product-
focused teams with frontend and backend people mixed together, but as products
become more about frontends consuming services, it seems that might imply a
different team structure is better. (And kind of a variation of how Conway's
law is stated in the OP since the architectural progression is driving the
team structure, rather than the other way around.)

~~~
jerf
Well, I'm sort of running that logic in the reverse direction... I'm pushing
microservices because our organization is already set up with a lot of
independence in the teams, and we've been struggling for years with coding
methodologies that fight that by trying to enforce monolithic coding
practices.

Conway's law is really important, but like mathematical equality, it doesn't
really have a direction. You can bring organization into conformance with
code, or code into conformance with organization. The full situation, as
always, may suggest one or the other is a better idea, but Conway's law just
says that you really need to do one or the other, or you'll pay a price.
(Which may also be one you find yourself having to pay for other reasons...
sigh... "ask not an engineer whether something is a good idea, for he shall
say neither yea nor nay...")

------
rmorgan
I totally believe in Conway's Law; I see it everywhere.

Christian Bird's chapter in Making Software
([https://books.google.com/books?id=DxuGi5h2-HEC&pg=PA187&lpg=...](https://books.google.com/books?id=DxuGi5h2-HEC&pg=PA187&lpg=PA187))
turns Conway's Law on its head with Conway's Corollary. Instead of fighting
organizational bias, embrace it.

"... all things being equal, a software effort that pays attention to and
actively aligns social structure with technical structure will fare better
than one that does not."

------
k__
Is this the reason why small startups can tackle big companies?

~~~
ThrustVectoring
I suspect that has more to do with the fact that communication and management
overhead tends to scale with the square of the size of the company.

