In my previous post whereby I lament the lack of companies willing to offer remote work, I wanted to touch on some of the arguments against using remote workers (and remote developers in particular) but felt it deserved a post on its own. And as luck would have it, half the post has been written already in the comments to the last one. Jimmy Bogard has one that I couldn't have planted any better if I tried:

"Remote team members that aren't in the same time zone +/- 1 hour, are very difficult to work with. [...] Even with remote team members in a close time zone, we noticed that 1) they missed out on important human conversations that led to 2) them not really being part of the team.  We kinda strive for the XP-style Whole Team, which can be very difficult to make work with remotely."

You may not believe me but these were the exact same three points I was planning to bring up anyway in this post, even without Jimmy's fine segue. His sentiments are echoed by other comments, many of which point out correctly that agile requires a lot of face time.

Yes, there are some obvious and no so obvious challenges on both sides when dealing with a remote worker. From experience, I can tell you that you can manage reasonably well with a time zone difference of +/- two hours but the fact remains, time zones must be taken into account. If you're on the east coast of North America an d have a regular 8:00am stand-up, your Vancouver-based developer had best be an early riser.

Several people brought up what I find is one of the biggest disadvantages to not being onsite: the hallway conversation. I know I've said this before somewhere but you would be amazed at how many major decisions are made at the coffee machine. Design, architecture, new features, it doesn't matter. Never forget: Humans have far more experience with the verbal word than the written one.

As was also pointed out, this is more pronounced in agile environments, where face-to-face communication is built-in to the process. Daily stand-ups around a scrum wall filled with post-it notes does not lend itself to remote developers. And no matter what technology solution you use to mimic it, there will always be a disconnect.

Unfortunately for me and remote workers in general, what these add up to is that it's  probably not practical in an agile environment to have more than one or two remote developers. There is simply too much focus on direct communication among the team that no amount of IM, e-mail, or internet telephony can overcome. But I would absolutely *lust* after whomever is able to prove me wrong.

None of these even take into account the most important factor: the skillz and personality of the actual developer under consideration. Interestingly, only Dave Woods mentioned this in his comment, almost as a footnote. Not everyone is capable of working remotely so this is something employers need to determine as part of the interview process, as if it wasn't difficult enough. Not to mention the fact that you are likely interviewing the person over the phone.

In the end, these are concerns that, like any other, need to be weighed against potential benefits. It's likely that these issues are so esoteric that most managers simply don't want to deal with them. They can deal with a shortage of good local help by commiserating with other managers who are in the same boat. It's a well-understood and widely-accepted problem and when you complain about it, people nod knowingly and say, "Yeah, tell me about it."

But if someone were to say, "I can't believe I have to schedule our meetings before 3:00 because of this guy we have working from the Bahamas", you had *better* be productive.

Kyle the Lamented