A Short Rant About Working Remotely

Given recent studies on multitasking, and the time it takes to get back on task, this does not sound like a positive thing.

"an ability to share work artefacts significantly challenge the effective collaboration of remote stakeholders"

Most "work artefacts' in software development are digital (and easily shared with the modern internet), and thus distance doesn't matter. This is obviously different from when this study was published in 2002.

The delay mentioned in the 2001 ieee article is virtually non-existant in modern work-from-home settings, where people are constantly connected by DVCS, screen sharing, skype, google hangouts, etc.

Yes, I'm cherry-picking problem quotes from your cherry-picked quotes, and don't have any studies to back up my beliefs (other than my own experience, which is frankly enough for me). That said, most of your citations are old, don't take into account research into human multi-tasking on complex projects, and don't take into account the tremendous advancements in remote communication that didn't exist as little as 5 years ago (github, google+, skype group calls, Trello, Bitbucket, Facetime, etc.)

Yet another anecdote: the last open office I applied to was definitely a war room... Warmachines, that is. I can't imagine getting anything of value done in that kind of environment.

In a completely remote team, you are forced to optimize for coordination and communication. Obviously you suffer the downsides because there is no water cooler, no joint information dissemination sessions, no war room accountability though you can achieve some kind of co-creation using skype, join.me, git and trello. However you gain some big advantages in terms of finding the right resource at the best cost, undivided focus if remote team members are given work packages and ability to exploit the timezone difference for a 24hour work cycle. Not to mention the humongous personal flexibility which it affords at an individual level.

A point to note is that this remote vs. colo experience really can come down to the individual members and their personalities. There is no one size fits all.

TL;DR Go completely colo or completely remote, half-colo + half-remote = half-ass. Team personality is a very strong variable in this equation.

It was a great set up for me - if I wasn't feeling productive at 9am I could defer until later when I was in the zone. I tended to work at night when my brain was buzzing, and got much more work done compared to now.

Post move, I am now required to work 9-5 at a desk in the company office. I honestly feel like my productivity has plummeted. Work loves having me there because I can play a more senior role to the more junior/less skilled developers, but my pay hasn't changed and I don't really feel like I benefit from it.

Perhaps I was just blessed for too long, and need to get used to what working as a developer in this day and age is actually like for the majority.

That said, you get right to the heart of the matter: the interactions between kernel components are well established. Sufficiently so that one person can work independently on a subsystem and another on a driver.

In my own personal experience, designing component interfaces is the most important aspect of building a system, especially when you are working with a team. Very often, I have found that the "all in one room" development model is implemented because the team lacks the ability to define those interfaces first. They are very fluid and so it's necessary to be able to lean back and yell at the guy working on the driver or subsystem and say "yo, I need this additional parameter". On a distributed team you need to write that in an email and that extra effort is often seen (rightly or wrongly) as a major bottleneck.

Where I have seen companies fail to work successfully with geographically distributed teams, it has generally been because their "all in one room" culture has allowed them to establish an adequate process/culture around designing quality component interfaces in an efficient manner. This inability to define quality "contracts" is typically what leads to slipped projects and missed expectation. Often times, it is what plagues teams that are co-located.

If you can do a good job at defining system components and their interfaces, doing the development independently and distributed is easy. You can write test harnesses and stubs around those APIs. The question is: can you work on that design process in a distributed manner as well?

In my experience, it doesn't matter, local or remote. Designing component interfaces is hard work and hard to get right. But it is essential.

I read the usual CS papers, plus lots of PhDs thesis. I follow the references in the bibliographies like crazy, and I also look up the writer's on the 'Net and see what other stuff they've done/written.

It feels like detective work, actually: the most-cited papers are frequently not the best. There's tons of researchers working in obscurity but who nevertheless have useful results.

I see my role as taking advances from research and bringing them into practical use.