
Allen Curve - brudgers
https://en.wikipedia.org/wiki/Allen_curve
======
Gys
'In communication theory, the Allen curve is a graphical representation that
reveals the exponential drop in frequency of communication between engineers
as the distance between them increases. It was discovered by Massachusetts
Institute of Technology Professor Thomas J. Allen in the late 1970s.'

So this was well before mobile phones, Skype, chat, etc, etc. I wonder what
the results would be for the same research done today.

~~~
toolslive
There's a chapter in "Making Software" about "Conway's Corollary" that makes
the claim that distance in the hierarchy matters more than physical distance.

~~~
Gys
Meaning that two engineers on the same hierarchical level but different parts
of the world would more often communicate then a low level and a high level
engineer in the same building ?

~~~
cma
I think he means other engineers, in a different branch of the tree, whom are
even more distant than someone is higher up but in the same branch.

------
theophrastus
From the point of view of (global) pharmaceutical research, I was a humble
witness of this precise issue being particularly badly managed. Within the
research groups we understood these problems of technical communication and
begged that projects be divided so that only geographically proximal sites
held 'whole' projects. But, the executive world had been trained to some shiny
new global view of spreading projects out 'evenly' over sites. Problems
incurred were immediately declared to be a correctable flaw of middle level
management communications. I tried to promote viewing the sites as one might
view separate CPU cores, and to divide projects only when they were
"Embarrassingly parallelizable"
([https://en.wikipedia.org/wiki/Embarrassingly_parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel)
), this was instantly overruled for lack of formal management training, (and
failure to use the 'correct' terminology).

~~~
DougBTX
> and failure to use the 'correct' terminology

This one I can understand from a teaching perspective. Often new concepts come
along with new terminology, but the up-front cost of learning the new concepts
can be reduced by expressing them in vocabulary the person already knows. For
example, with non-programmers I find myself talking about text and letters
rather than strings and characters because the differences can be glossed
over.

------
paulsutter
The folks at Slack would have excellent data on how this works today. I'd love
to see any analysis by them.

Anyone from Slack on here?

~~~
pavel_lishin
Do they have geolocation data?

------
angersock
I was working at a place where the CTO was remote--same city, different
building, maybe 15 minutes away by bus or whatever. They had a "day job" as
some ivory tower researcher.

We basically endeavored to remove them from as many decisions as possible, and
tried to find ways of working on the codebase so they were no longer the
single owner of things. We didn't go far enough, I think.

Their priorities weren't really our priorities and vice versa, because they
didn't see us suffering through their design decisions, and because whenever
we brought up new features or tech it was always kinda seen as a potential
threat to their research ("Well, if this business fails, I've still got to
maintain everything, and at least I know how to maintain what we've got", "Oh,
well, that change means I would need to reprocess all my collected data",
etc.).

They would go and talk to folks and wheel and deal, and it was apparent to us
that they never really knew what was happening "on the ground". Least of all,
this meant that they favored solutions that were very conservative. They
weren't good at scheduling tasks because they had a mental model of how long
their part of the codebase took to work on (taking into account frequent
external interruptions that the dedicated FTEs on our site didn't have) and
they didn't feel any burning need to transfer their knowledge to us because
that was a slow and annoying process (we only saw each other a few times a
week, maybe in the afternoons after work for like an hour...hardly enough time
to do a technical handoff, so why bother).

It was pretty frustrating.

EDIT:

To tie this back in...we had email, we had a group chat I pushed for, and
other things. It's just that the little things like being able to look up from
your desk and judge by their body language that something is bugging one of
your engineers or physically pinging somebody who hasn't answered on chat for
a while were missing.

There's also the chat problem of doing a batch update on chat messages and
because of timing and the inability of text to accurately convey emotions
having a big misunderstanding leading to a grumpy phonecall. That happened a
couple of times.

------
lifeisstillgood
I wonder if the ability to see a face (ie in a hangout) increases
communication - I worked remotely from UK with several Texans, and anecdotally
when we switched to hangouts / video Skype we had notably more breakout
sessions etc.

Phone did not cut it

------
Gys
'The finding also revealed the critical distance of 50 meters for weekly
technical communication.'

Cannot imagine this is still valid today. There could not be remote workers.

~~~
calpaterson
Well, it was valid at the time and people still put engineering in a different
office from sales. The fact that something doesn't work doesn't stop at least
some companies from trying it. I have (relevantly recently) heard of an
organisation that had their technical architects in a different office from
their engineers

