Whenever I've seen this done, the very best employees leave. I am a firm believer that you can train yourself to hop in and out of a reasonable facsimile to the "zone" in much less than 20-30 minutes (I do it all the time)[1]; but the level of distraction of the warroom type environment massively favors your more extroverted engineers. My experience has been the engineers I really want to keep, the ones who solve the really hard problems, are much less likely to be in that group.

In short, you may double your productivity for building that CRUD application, but when you have to solve that really hard problem, you may find you don't even have an engineer who is capable.

1. There is a level of concentration, the "real zone" below it that most development doesn't require. However, when it does, the interruptions become catastrophic.

If you've got a super-top engineer who can solve the hard problems, then they're probably working on something of their own, and can be off in their own room / at home / whatever.

But in my experience, that kind of "hard", mentally intense, non-collaborative work makes up only a tiny, tiny fraction of commercial software development (although it contributes a great deal to the value). So it's not something to base general development practices around; it's the exception.

As you say -- "double your productivity for building that CRUD application" -- that's exactly the point, that's what most companies need, and why most companies aren't interest in remote working.

When they suddenly need a top-level engineer to solve a hard problem, they hire one who consults for three months, works remotely, and visits once or twice.

You've essentially described every job I've had since college. That's exactly my experience of how companies actually work in practice.

Then, I look around for companies that need a problem I already have a solution for solved, and I pitch my solution to them. Sometimes, I'll take jobs to solve problems I haven't considered before, but that's rarer.

If they like my solution, I set up a contract to implement it for them.

I'd say about 50% of the time I pitch a pre-existing solution, I get work. What's great is I'm essentially picking my own work and I get paid well (because the problems are hard).

The downside is you pretty much always have to be coming up with new solutions to things, and stay very current on technology.

I'm generally into something long before the "early adopters" get there, and I'm gone by the time it hits the mainstream. For example, I was working on a Google Spanner-like database while Google was doing the same.

At the time, no-one thought something like that was possible (outside of Google -- and they didn't tell anyone). I implemented different parts of the solution with three different clients over a two year period, none of whom hired me to create something like Google Spanner, but all of whom needed one part of the whole package solved.

I have a couple of times found myself inventing solutions to problems I had in the business, only to see them appear as cutting edge open source at the same or a little later (ie Python deployment tools)

I have always assumed one needs to be working in an area, pushing hard and then finding that "what no-one has an answer to this!?" moment.

I would have trouble believing I could find a solution at the cutting edge, and find the people who needed it, without being knee-deep myself.

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.

What are some examples of the best research that is obscure?

In general, stack languages are great for graphics in both 2 dimensions (PostScript) and 3 dimensions (GML)[1].

[0] http://digisrv-1.biblio.etc.tu-bs.de:8080/docportal/receive/...

[1] http://en.wikipedia.org/wiki/Generative_Modelling_Language

2. Networking, Networking, Networking

3. Be willing to talk about yourself a lot.

4. Act Confident in the face of uncertainty.

Also once you decide that you want to have a professional career jumping on technology grenades, do not work as an employee. I made that mistake. The nature of grenade jumping is that your are asked to solve a hard problem that needs to be solved in a short time, if you are an employee this amounts to massive hours, (70-90 hour work weeks), of unpaid overtime. Work as a contractor and be sure to bill for every hour. Or be sure to get a very healthy option grant if it is a promising start up. My life has been much happier once I started doing that.

Also be sure to work out, this sort of work takes a severe toll on your health if you do it for 20-30 years.

I'm curious given your experience. My biggest issue is that I don't know what a 'hard problem' is, I know what comes naturally to me, and what takes me some time to grok, but my experience is that those problems that come natural to me seem to be extremely obtuse to others.

So what types of problems do you solve that allow you to market yourself in such a manor?

I assume you have NDA type structures in place so I expect very general responses.

Secondly, you're assuming that the best developers are going to be more introverted than the developer culture/profession as a whole, which I don't think is accurate.

This is highly underrated wisdom.

If you focus on always hiring "Rockstar developers," you'll find yourself in a miserable situation of competition and egotistical conflict. Hire your team, not your developers. Get your team working like clockwork with good systems and good relationships, and your company will be rockstar with whatever people you throw at it. Look at github, stripe, twitter, facebook—you think they only hire the absolute best developers? No, they have a top 2% just like you will—your goal should be to increase the competence of your entire company, not just ignorantly hire the best and fire the worst and hope for the best.

Spot on.

You're right about the other assumptions too (though the parent may not have been that serious about them). IMHO stereotyping introverts or extroverts as being better or worse at certain tasks is a huge --ism to avoid, especially in our field. I see 'extrovertists' and 'introvertists' battle it out all the time with their propaganda and ignorant beliefs about people, and no one wins.

It's far better and more productive to be a humanist and find a good balance. Both extroverts and introverts can be valuable to your team; both extroverts and introverts can be great programmers and workers. You should strive to hire a mix, or stop using it as a metric and naturally get a mix, since these traits like many others generally fall on a normal distribution.

Don't trust your assumptions about yourself, and don't apply them to others. They're probably wrong.

This leads to an interesting thought - if you hired Linus and he started spending all his time emailing sarcastic notes to the other developers, how quickly would he get fired for "not focusing on developing code"?

Perhaps the key for CEOs is not to grow culture but to hire people who will grow it for you. You dont get to choose the culture, or even direct it. The funny Finnish bloke will. You just pay him.

I don't see the problem. People who make cool stuff and solve problems in their spare time are the ones you want working for you. Even if they waste time sometimes going off on tangents, it's probably honing their skills and improving something relevant to your company or their own work abilities. No problem, you want that. Trust them to do the right thing.

So you need your lead to be awesome. But the rest can just be good people who know how to code.

* this would be someone who may not fully grasp all the concepts and sometimes writes bad code, but is open to learn and listen. There are developers who write bad code and are arrogant/confrontational about their abilities. Those should be identified and fired as quickly as possible. They will sink your ship.

I don't think that's the assumption at all. My personal experience is, unless you happen to be located where one of the "best" developers is, they simply won't move. So you have your choice of them working remotely, being lucky, or not hiring them.

I took this to mean (a) be relative to the office specifically, not the industry generally, and (b) that those very best will get sick of the required face time, quit, and get a better job (the insinuation being that that better job will likely be majority or entirely telecommuting. I may have misunderstood the intent as I commented pretty much immediately after reading it.

I just generalized it to my experience, which is less about introvert/extravert and more about "bad conditions force good people out/prevent good people from being hired"

I, too, read "group" as "extroverted engineers," and I don't really see alternative readings.

Getting interrupted kills my flow. I'm less productive as I get back into flow (although I have techniques now that let me get into flow much quicker - but that's a separate post).

However - is that drop in productivity outweighed by the increase in productivity of the interuptee not having to wait / switch tasks / fumble on and make a mistake / build the wrong thing / etc.

If I were to estimate, this probably doubled efficacy of our junior devs while halving the (direct) productivity of senior folks. In my cases, it was immediately apparent that we came out ahead: the former outnumbered the latter by several times.

Did you also see the incidence of "bad" interruptions drop as the team got more experienced? That's what I've seen pretty much every time I've worked in this sort of environment.

I really like this. I consider myself an intermediate developer, and can't even count the times a 5-10 minute conversation would have saved me an entire day - or week! - of wasted effort. I think this is easily overlooked because its not totally obvious that interrupting a highly productive, highly skilled developer could result in higher team productivity.

So I think about ways I get get back into those cycles quickly. To do that I try and cut up my work into the right size chunks, have a plan, and leave work with an "easy win" so I can get back into the loop again quickly.

Some examples. Hopefully I'm not descending too far into life-hacker wankery here ;-)

* I TDD code, and always try and leave myself with a failing test. If I'm interrupted and don't have a failing test I will deliberately break something or hit undo enough times to get a fail so I have an easy win when I get back.

* I don't track time on task. I do block out time for tasks - and track non-relevant interruptions during that time and see if there are ways to stop 'em happening.

* I run a personal kanban board for stuff so I can keep that continual ping of reward happening during the day.

* I breakdown tasks as they come in so they I can get little reward pings on a regular basis.

* When I have real problems getting into flow I give myself automatic rewards (do 20m on X then you can do 5m of fun on Y). Similar to http://en.wikipedia.org/wiki/Pomodoro_Technique. Once I get started the normal task-achievements often mean I don't actually end up doing Y - it's just a personal hack to get me started.

Basically - fake the reward cycle until the real one takes hold.

Make vague sense?

But for most tech startups, I'm not sure "the really hard problems" are the technical ones, because we are good at technical problems. Perhaps the really hard problems are how to get early traction, how to build something people love, and how to make the business profitable. Some of those hard problems might be easier to solve as a face-to-face team.

I've seen that happen (which brings up the separate question of does it matter if the team is N x more productive because of co-location)

I've also seen them stay.

I've also seen them start out very sceptical and then grow to like it (I was in this category - assuming I'm vaguely competent of course ;-)

I've also seen folk I hugely respect advocate and instigate this sort of environment.

.... so which anecdotes win... dunno... hence call for any folks who have found research on the topic.

It takes some commitment to make it happen. Without everybody committing to a low-distraction workplace, volume is definitely the default. But I think the benefits of a team environment make it worth the effort.

As a management major (do regret) I was taught that it only works when there are clear definitions and metrics for success, especially routine tasks that require less creativity. I don't see that backed well by modern research, and I wish we had better research.

I also feel the anger people (especially programmers, it seems) feel about not being able to work remotely is misplaced. If it upsets you that they want people to work face-to-face, you're probably not a good fit for the company culture that requires it anyway.

The open office plan is a nightmare for tech work IMO.

(Part of the confusion may be that "war room" and "open plan" are not synonyms. The former only includes people actively working on the project. This is not the environment where you have the sales guy yapping on the phone.)

That is why I firmly believe that given any team, it is best to have them collocated in a large but private room.

However, we are not talking here about the optimal location for any given group of programmers. We are talking about finding an optimal group of programmers without having to exclude those outside a 20 mile radius of your geographical location.

As far as really getting into the "zone". What I do is put my headphones on, pipe some white-noise in and in a minute or two it's no different then working by myself in my home office.

IMO the best working environment places the team in conversational proximity, but provides an option for individuals to find isolation (either in a dedicated room or at home) when it is necessary to solve a hard "real zone" type problem.

And its trend was increasingly remote. Members sought this once and as they could, because it increased their effectiveness so much. (And lowered costs and total time demands -- e.g. commuting -- in positions that were already delivering far more than 40 hours / week.)

This team outperformed the other teams by a fair margin. And some of the truly remote members were among the most efficient and effective I've seen.

Throughout my career, I've seen very little evidence that physical presence -- colocation -- makes a significant positive contribution in software development. I am biased, I will say, in that I both prefer and need a quiet work environment. I feel validated or "justified" in this need, for me at least, in that I've consistently been one of the most effective employees in the organizations within which I've worked. (And I've had numerous people in all sorts of roles tell me this.)

I don't mind colocation, if quiet offices are provided. However, cubes or worse are largely de rigueur, these days, and even in such open space environments, I've witnessed not just the destructive nature of noise and interruptions, but depending upon the staff member enormous amounts of time wasted on "socializing" of various (very off-topic and sometimes inane) sorts. Doubly bad in that context, in that it invariably distracts surrounding employees who are trying to work. And it builds a conflict between not betraying teammates and one's own need to have them quiet down or take it elsewhere.

As for who tends to "thrive" in such environments? Those who "multi-task", juggling lots of things shallowly to the point of making many mistakes and oversights. Those who are constantly "interacting", meaning most often that they are interrupting someone else to solicit knowledge that they should have or be able to look up themselves. Those who use the concept of "team" to disperse and deflect individual responsibility.

Granted, I and the people I've described may be a minority. But in my observation and perhaps in staid corporate environments, those who benefit from colocation tend to be those who need to be herded and hand-held. Those who want and are really able to get shit down, don't mind face to face but are greatly frustrated with pointless and distracting face to face.

(As an example of this latter, we got many of our meetings down to 15 to 30 minutes, when they were necessary. People knew and held themselves responsible for knowing what was up, and the meeting could quickly focus on problem solving and setting a specific course.)

I too don't know what the numbers are like. I've seen great teams do great things remotely. I've seen great teams do great things co-located. Some of the very best teams I've seen have been co-located. I've also seen some distributed teams fail miserably. I've seen teams co-locate, try remote working, found it didn't work, and co-locate again. And so on.

I wish I knew the relative spread of how these things work out for people in different contexts and on different projects. I just find it suspicious that remote work is often presented as all upside since:

a) In my experience things are rarely all upside - I always start looking for the downside ;-)

b) For whatever reasons a chunk of the dev world tends to be a tad asocial. I know I can be like that. So when something comes up that supports that tendency I wonder if I may be overlooking problems because I would like something to be true.

I'm plenty social. And I'm not a snob -- I can talk with most anyone, about genuine interests (interests on either party's part, not just my own). Or just sit around drawing spirals in the pancake syrup, for a while.

I don't particularly enjoy discussing the latest Hollywood movies and actors ad nauseum, whose existence and which conversation seems to serve significantly to reinforce established, simplistic stereotypes. Especially when the conversation ranges in exactly that direction.

I don't enjoy conversations that "get personal", looking for ways to pick apart those not present (behind their back). Or that look for ways to pick apart those present, in active, emotionally manipulative pursuit of a pecking order.

On the team I described, we socialized, although people were on average fairly reserved. A good part of that socialization reflected people actually paying attention to and remembering what each other were interested in and doing, and what was going on in their lives.

Again, this is just an opinion, but I think some of the "anti-social" attributed to "nerds" and "geeks" is rather an active dis-interest in much of the lowest common denominator of what we consider "social".

(Some, not all. I've met plenty of intellectual assholes, too.)

Another, personal example: I rather enjoy playing sports. I couldn't care less about watching paid professionals doing it. (This does vary somewhat by sport and event. Also, if anything, I tend to find amateur games more interesting; they bear a closer relationship to my life than the over-produced, over-medicated thing that professional sports has become. Upon reflection, maybe this is a somewhat arrogant or avoidant attitude on my part; I received a lot of abuse as a kid for not being "sports-wise" -- something my father wasn't and never passed on to me.)

I've spend too much time and energy on self-doubt, as it is. A lot of places and people have told me that I'm the one who needs to change. They love my work, and how do I do that? But, you know, "We all work in cubes."

If you are outperforming your peers (and, not infrequently, management) and otherwise succeeding, then, well, who has the problem?

The following may take the interpretation a bit far, but: The bully will always insist that it's "your problem".

The technologies we use to communicate evolve fast, and I would bet money on the fact that (probably because of mindset evolution and tooling) developers are now more efficient when working remotely than they were ten years ago. Moreover, as we are on HN, we are not necessarily talking about average developers, but more about the ones that are used to Git, IRC, Trello, and other tools which make remote work more doable.

Startup environments are not average, and this must be why companies like Github and 37signals can be successful while having remote workers.

Actually - several of them are. For example:

"Another field study compared interruptions in paired, radically-collocated and traditional, cube-dwelling software development teams, and found that in the former interruptions were greater in number but shorter in duration and more on-task (Chong and Siino 2006)"

This is one of the things I find fascinating. You see the same kind of thing over thirty years as technology changes radically. This makes me think that there's something quite interesting happening in meat-space.

Startup environments are not average, and this must be why companies like Github and 37signals can be successful while having remote workers.

Just to repeat. I am not saying that you cannot be successful being distributed. There are lots of good and sane reasons to be distributed.

I'm saying that there is a bunch of evidence that being co-located is more effective.

Today's homo sapiens brains function the same way as in 2006. Productivity of mental workers responds to disruptions in the same way as in 2006. A large majority of programmers and other people working now in IT are the very same people that were analyzed in 2006.

There are a few more options maybe - but nothing fundamentally different.

For example, a cell phone from today isn't fundamentally different than a cell phone from a decade ago. They're both computers and can be used to make phone calls. But with the cellphone of today, I can have a virtual meeting with anyone from anywhere, face-to-face. That alone is a huge improvement for distributed teams.

Need to have a concentrated task force from 5 various departments? No problem, it's a click away-- no need to book a meeting room, take all your gear (disrupting your workspace) and try to collaborate away from your desk in a mutual location.

Currently I sit beside people working that I previously worked on the same project with, but have now slightly diverged from. Trying to come up with a perfectly co-located office plan wouldn't work, because some number of people couldn't help but be misplaced. Not to mention we'd have to do it every few days!

The evidence from folk who study this seems to differ from this.

The world is full of anecdotes about how much better things are with the newer technologies - yet I can very little evidence that this is true. I know I'm really good at fooling myself about my own productivity. I don't imagine I'm unique there ;-)

And my personal anecdotal experiences over the years (including recent ones ;-) is that you can really ramp up productivity by getting everybody on a distributed team in one place. Even when everybody is normally skyping / IMing / whatever.

Not to mention that most productivity studies are bunk.

The real reason many so many managers resist remote work is because, effectively, they want a fiefdom, and the exercise is often about empire building. An empire of a bunch of Google Talk connections isn't as impressive as a bunch of huddled seat warmers.

However with a cursory glance over the references, they seem heavily biased towards a "crunch time, in a war-room" scenario.

This can lead to large productivity gains for reasons unconnected with physical location

(Clear short term goals, only the best get invited into the war-room, daily distractions and resposibilites are lifted, a fostering of elitism compared to the outsiders)

However I cannot see a long term study on this (I may be wrong).

My "gut feeling" is that regular funded sprint meetings plus remote working is an area of research that may well yield best long term trends.

But wheres the proof :-)

Not churlish - maybe misguided ;-) I'm really not trying to suggest that distributed work is bad / evil / fails. Just that - all things being equal - colocated teams win. That there is a substantial body of evidence that not being colocated carries a substantial productivity hit.

My "gut feeling" is that regular funded sprint meetings plus remote working is an area of research that may well yield best long term trends. But wheres the proof :-)

Indeed! It's the complete absence of "distributed teams do X and Y better" research that I find fascinating. Unless it's hiding in a corner that I've not been able to find.

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.

  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.

What matters is this:

(1) The software company needs your software skills more than you need the company.

(2) You decided and plan your life around telecommuting.

(3) So telecommuting is non-negotiable.

Non-telecommuters tend to be wary of remote workers, not because they are any more or less productive. There's an underlying fear and a need to control risk. A manager who is not used to this want to reassure himself that things are going smoothly. You address that, then things fall into place.

In other words, the managers, speaking for the company say they want more "productivity". What they really need is more control and reduction of risk. They feel a certain level of assurance when they can see people walking into the office on time, every day. It assures themselves of their own continued employment. Give the manager what he needs (the assurance), and this conflict goes away.

As for recruiters, at the end of the day, they are salespeople trying to close a commission. There are only a few exceptions where a recruiter acts more like an agent, rather than trading you like a commodity. Obviously, such people are worth keeping contact with.

I don't think that it's always this clear cut.

In other words, the managers, speaking for the company say they want more "productivity". What they really need is more control and reduction of risk. They feel a certain level of assurance when they can see people walking into the office on time, every day. It assures themselves of their own continued employment. Give the manager what he needs (the assurance), and this conflict goes away.

This isn't always true - or necessarily often true. Most managers I've deal with over the years are much more focussed on productivity than control. Some maybe think that control is the best route to productivity - but that's a different problem to solve.

For a start - everybody here who's building a startup. As soon as you get employee #1 - congratulations. You're a manager. Are you suddenly unconcerned about productivity ;-)

As somebody who is considering non-founder hires in the next year I'm thinking about ways that I can have them be local and co-located. Despite the fact that this may involve getting an office for the first time, possibly moving locations, hiring newbies and training up rather than hiring for skills, etc. Because, in my experience, the productivity gains could well be worth it. I'm going to experiment at the very least.

If you only address that want, then you are not addressing the underlying need.

Lots of people say they need to get stuff done, but that is not the true underlying need. These are usually driven by deeper motives, generally relating to need for parental approval (fame, glory, success, achievement, etc.), need for security, and need to eat.

Why do you really want to build a startup? If you're honest with yourself, you'll generally find that your want and need don't match. (And if you are impeccable, and your want and need matches, things tend to go smoother).

(It seems to me that most software research stopped as the PC revolution took off)

Communications technology keeps getting better - yet co-location still seems to carry a major advantage. That is interesting to me.

But for programming, I find the best environment is an empty room, no distractions, headphones on, and NO ONE bothering you. That's not gonna happen at an office. Programming requires intense concentration, hard to get in a room full of people.

I'm willing to believe that, for some people, this is true. That they cannot work outside of environments like this.

There are also people who believe that they cannot work well outside of environments like this - but are incorrect (I used to be one of these).

There are also people and organisations who are very successful great developers who love and promote team room environments.

a) I'm not sure of the relative numbers of those groups

b) If the team room environments are a lot more productive then developers of the first sort are going to have long term problems getting work on projects that involve teams of developers

However, I know from attempting to hire even entry level engineers in sub-250k population areas, it can be very tough to even find a bare minimum candidate. I would jump at the chance to hire a rock-solid developer in a nearby city, state, or even country.

"Pretty much all the evidence (rather than anecdote) I can find shows that co-located teams in a single team room environment are the most productive - all other things being equal."

If you can think of a way I can express that opinion better I'd appreciate it (This isn't sarcasm - it's a genuine request. Judging by many of the replies here I'm expressing myself badly ;-)

There are plenty of good programmers living in relatively cheap places (Like the Midwest, for example). Pay someone in Minneapolis $10-15k less per year than what that same person would make in Palo Alto and that person could still end up above market for Minneapolis.

After all, traditional interviews bias for those who are good at face-to-face communication. There is basically no filter for those who suck at remote communication.

It's exacerbated by the fact that it takes more than one to communicate. If you work remotely, it's not sufficient that you are capable of writing an intelligible email. Everyone you interact with also needs this ability, which tends to be rare in companies that are not purely remote workers.

If scheduling our call was difficult, or if you were hard to understand on the phone, or if there was excessive background noise, I'd hold that against a candidate. If your emails were not clear and intelligible, that counted as well.

People who communicate well remotely stick out like a sore thumb when you are interviewing for those types of roles and if you value it. If you are just looking for warm bodies, I can definitely see how it would be problematic.

That's a really nice point that I'd not considered before.

It's exacerbated by the fact that it takes more than one to communicate. If you work remotely, it's not sufficient that you are capable of writing an intelligible email. Everyone you interact with also needs this ability, which tends to be rare in companies that are not purely remote workers.

The problem is that, from what I've read, the productivity advantage that folk get isn't through the sort of good communication you get from writing effective emails. It's the more ambient communication you get from noticing your coworker has been staring at the screen without typing for a few minutes, or from hearing and correcting a mistake automatically.

A reduction in health risks and distractions are two of the noted benefits. If productivity depends highly on teamwork, telecommuting may not be ideal, but it should improve individual productivity for the right employees.

I'd be interested on whether the comparison is to general open plan offices vs team rooms.

A reduction in health risks and distractions are two of the noted benefits

Health risks? I wonder why. Most accidents happen in the home and all that ;-)

You'd lose that bet. There are a variety of different methodologies and areas studied.

Companies that embrace remoteness from the start (like GitHub) seem to be doing fine, precisely because they treat remoteness as an asses, not a minor concession someone had to make to workers.

Again - not trying to argue at all that people cannot be fantastically successful as a distributed team.

What I am saying is that every single piece of research I can find says that colocated teams are more effective. This is... interesting... to me.

How much of it was looking at teams that are "super distributed", for example, between the US and India, where major differences in time and culture can play a huge role compared to say, a team distributed between Chicago and New York?

http://possibility.com/Misc/p339-teasley.pdf

http://kraut.hciresearch.org/sites/kraut.hciresearch.org/fil...

This one does not seem to involve developing software:

http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjourna...

Remaining two articles are not publicly accessible.

Granted, it doesn't study efficiency but defect rates, but having development distributed geographically was shown to have little negative effect.

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.

The question is when does an on-task interruption stop being something that switches modes. Also while the cost of task switching for an individuals productivity may be bad - it may be a net good for the team as a whole.

(BTW which recent studies? Interested in this since most of the multitasking research I'm aware of is pretty old and has the same general message of "it sucks". Would be interested in newer angles on this. Been away from academic cog-pych libraries for a while ;-)

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

My experiences have been mixed, but much more positive for co-located team rooms as I've seen folk try different alternatives.

Personally I'd say that the most productive teams I've seen have been co-located - and I've seen several teams who have deliberately moved (temporarily in some instances) to co-locate because they find it works better for them.

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

Most are old - but not all. I also think we tend to overestimate how much things have changed technology wise. I was using video chats, distributed source control, etc. five years ago. What we have now seems to be incremental improvements not game changers.

When I first started looking at this sort of thing six or seven years ago people applied the same arguments about email / internet / web....

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.

My experiences have been different. An anecdote battle would probably be pointless - but some other folk in the thread seem to have had similar experiences.

I find it interesting that there's been no newer work showing clear benefits - which is why I'm looking.

Working on many different teams in numerous cities over the last few years, the bullpen and shared space is one of the best ways to remove silos and promote organic conversation (kill meetings). Pairing instead of code reviews (or gated checkins), talking instead of team meetings, one on ones instead of political games and going out for coffee to think through a hard problem. With the right team, you show up at 9am and leave work at 10am (really it is 5pm, but it feels like 10am).

I tried quite hard in my post to say that I thought there were valid reasons for doing remote work. Just that the balance of evidence that I can find is saying that co-located teams are more productive.

I'd appreciate it if you could let me know if I've expressed myself badly - and any suggestions on expressing myself better are would genuinely be appreciated.

As I said in my post - I telecommute a great deal myself. For pretty much exactly that reason you outline. I am really not trying to say that telecommuting is bad ;-)

My comment was not a poke at you, just the absurdity of not allowing it at all.. if the alternative is worse.