My own experience is that in small companies and small groups communication is critical - and this means real-time, interactive, face-to-face interactions, usually non-electronic. When trying to solve hard problems a few people working at a white board or around a table can accomplish in hours what can take days, weeks, or forever when working remotely.

This suggests to me that "work from home" or "remote work" are useful, but must be used carefully. I would tend to make work-from-home the exception and work-at-the-office the baseline.

My own experience with this is that once a group gets a lot of face-to-face experience then members can experiment with remote work. But they should anticipate that there will be problems and perhaps the attempt might need to be abandoned.

Measuring performance is hard. Google measured it by lines of code. Which drove some people to simply re-tabulate existing code. Git and Subversion took those lines as changed even though nothing had actually changed.

A friend wrote some code that saved Google $millions upon $millions by extending the lifetimes of storage media - but the code was small so Google gave him a negative job review.

Writing code at home is quite a different thing than solving problems. For instance, when we were doing IP/TV (Precept Software which merged into Cisco) Steve Casner and I had to work with our desks stuck back to back so that we could work on ideas about how to deal with all of the near real-time issues of moving multimedia over the net. Steve was a god with math and algorithms, I was really good turning that into code. Had we been in different locations we couldn't have made progress at a rate anywhere near what we did.

Same when Vint Cerf, Dave Kaufman, and I were trying to figure out how to insert a cryptographic layer between TCP and (the then yet to be publicly born) IP. We had to work together, sharing our blackboards (with chalk!), and gobbling down delivered pizza. We couldn't have done that without being in one place, especially given that once outside of that room we had to jump through many military security procedures even to exchange papers or emails.

Once a clear method and goal is established and it comes down to writing code to do that, then isolation is OK for a while - until testing is needed (after one tests his own code it is important that fresh eyes do their own tests.)

@Andrew Pam - When Steve Casner and I were working together we had online chat and even Van's "wb" (whiteboard) (we often even had Van himself at our office) but even the modern shared whiteboard versions seem to need a baseline built on a baseline of actual face-to-face work in order to function well.

It's sort of like my experience with ICANN - they tried a lot of electronic means and until we had spent a great deal of time interacting (or a lot of travel to be in the same place) there was a lot of mis-communication. My own metric was that we needed to work together long enough so that when we connected (non-facially) electronically I would hear their own voices arise out of the text.

When interacting electronically I found that it is useful to presume that I would be mis-heard (or that I was mis-hearing) so I adopted a method of skeptical writing - which to be redundant, often verbose, and to invite questions and to admit that I might be quite wrong.

(My lawyer training made that hard - from that I got into styles that were more assertive and conclusionary rather than conversational and inviting - that's a problem I fight even to this day.)