[falcolas]

I feel that TheOtherHobbs covered most of the points really well, but I feel that this point needs a bit more direct discussion:

> you still have to plan the call, set up a time, etc. There's friction to spontaneous collaboration, and spontaneous collaboration is what people really care about when they talk about the benefits of in-person work.

If you value developer productivity at all, that little bit of friction is a _good_ thing. It means that you have to think for a second about the most appropriate forum for that discussion. And if you decide that you do need to talk to someone, the friction isn't really that high. Click on a user, click on the green button with the camera on it, and you're talking.

In-person spontaneous collaboration is, in my experience as both a developer and a development manager, highly overrated, and the value is very rarely worth the costs. Those costs include lost productivity, developer stress, bikeshedding, and an implicit culture of hostility to anything that doesn't _look_ like productivity (like thinking).

Taking a moment to put on my development manager hat, one of the things I never want to do to my developer employees is interrupt their flow. I go to meetings, so I can give them a brief summary which contains only the information they need to do their job. I work with the customers and listen to 50 minutes of rambling so I can glean the 5 minutes of information my employees need to do their work.

I've hired them, and I'm paying them ludicrous amounts of money, to create programs; to create value for the customer. Anything that gets in that way is up to me to address and remove. And based on my experience as both a developer and a manager, those "spontaneous collaboration" interruptions are usually something that needs to be addressed and removed.

[nostrademons]

This still doesn't refute the point timr was making: sometimes the most productive thing you can do is stop a programmer from writing code. As a programmer (and an employee), what you're ultimately responsible for is happy customers and solved problems. If your code solves the wrong problem, it has negative value to the organization, as it's just something that all the other programmers will have to trip over later.

The value of colocated employees is being able to really quickly recognize and correct for when the code is solving the wrong problem. Whether that outweighs the increased individual productivity from eliminating distractions is very much case-specific, which is perhaps why there's so much heat and so little light on this issue. You'll never capture all the complexities on a web forum.

[falcolas]

> sometimes the most productive thing you can do is stop a programmer from writing code.

I have little to dispute about this statement, but I disagree that being colocated has any effect on this (unless stopping them 4-5 times a day will truly make the team more productive; at which point a manager needs to step in and fire that person ASAP).

> The value of colocated employees is being able to really quickly recognize and correct for when the code is solving the wrong problem.

How does colocation solve this where remote does not? Do you expect that your co-workers would somehow notice this from looking over someone's shoulder, as opposed to when you pull in a branch of code from your VCS?

Once you've pulled in the code and notice the problem, you can bring it up in the next scheduled standup or hit the little green button next to their name in Hangouts/Skype/...

I can not see how being colocated would do anything to help speed the discovery of this particular class of problem in a way which is not practical using modern telecommunication software. As a point of reference, I have personally pair coded (with anywhere from 2 to 5 people) with folks in England with great success.

[nostrademons]

From personal experience, the most common way this comes up is that you have a casual hallway conversation with a colleague, they ask "So what are you working on these days?", you tell them, and they respond with "You should talk to so-and-so, he worked on that a year ago and may have some insights" or "Have you heard about technology Foo that's designed just for that problem?" And then you follow up on that lead and realize that the project you just budgeted a week for (and will end up spending a month on, given all the unexpected problems that come up) can be solved in a couple days if you approach it slightly differently.

These are not hypotheticals - there have been numerous points in my career, ranging from being a sole technical cofounder to working in a 50K+ employee company, where a chance meeting has saved me weeks-to-months of implementation effort. And in each of those cases, the solution they suggested was not something I would've thought to look for on my own, because my starting assumption was that it needed code to solve. And similarly, it probably would not have been spotted until the feature was done and the time spent, because usually your coworkers' assumption when you embark on writing a solution is that the solution is necessary.

[akoncius]

it's very easy to make sure that it doesn't happen - for example in Scrum there is a term called "morning meetings", where team is talking about what they are planning to do, what they did previously, and talks about some issues if there are any.

I've seen many examples that exactly the same problem as you've written happens even in co-located team, so it's a problem of lack of communication, not of being co-located (or not).

[falcolas]

This still makes the assumption that these kinds of watercolor conversations are unable to occur online. They do, either in the form of chat logs, or voice calls prior and after meetings, or just as two people get the desire to BS for awhile after coding.

These behaviors are simply not constrained by the environment, not anymore.