Allen Curve | Hacker News Reader

Allen Curve

en.wikipedia.org

72 pointsbrudgers18 comments

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

In the recent developments part it says:

"We do not keep separate sets of people, some of which we communicate in one medium and some by another. The more often we see someone face-to-face, the more likely it is that we will telephone the person or communicate in some other medium."

My Slack communications with our Argentina team kind of follows this rule.

This podcast on distributed scrum, suggests some ways to "push the curve to the right".

http://www.se-radio.net/2011/12/episode-181-distributed-scru...

From my experience, the defining parameter is now the timezone difference (or, working hours kept), rather than distance.

There's a section on that article called recent development. https://en.wikipedia.org/wiki/Allen_curve#Recent_development

"For example, rather than finding that the probability of telephone communication increases with distances, as face-to-face probability decays, our data show a decay in the use of all communication media with distance (following a near field rise)."

It's not the tech, it's the behavior.

Did the research control for the fact that people in the same department or woking on the same project tend to share space?

If I'm working on Project Banana I'm not usually going to have a need to talk to someone working on Project Avocado, even if we're on different corners of the same floor.

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.

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 ?

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.

How do you compare those distances? How many meters is a link in the hierarchy?

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 ), this was instantly overruled for lack of formal management training, (and failure to use the 'correct' terminology).

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

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?

Do they have geolocation data?

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.

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

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

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

Reply on news.ycombinator.com