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