A handy technique for evaluating situations is this: how many mistakes am I away from death/injury? If I drive without a seatbelt, I've put myself 1 accident away in many cases.

My Scouts are young, and love to climb things. I tell them, I know you're strong and skilled. But a loose rock or slippery foothold puts you at risk anyway. So wear the harness - now it takes two mistakes to kill you (e.g. loose rock + badly rigged harness). The risk goes down drastically.

So put some non-skid floor mat in your shower, or a chair as advised in this thread. The mis-step no longer carries the same risk.

(lightly edited copy of my usual plea for evidence on this topic ;-)

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.

(And I'm saying this as somebody who spends a lot of their time working from home, and talking to other folk over Skype, etc. There are reasons for telecommuting - personal preference, getting access to people who cannot co-locate, etc. But for business productivity I'm not seeing much, if any, evidence).

I am not saying:

* That working alone in an office is bad / will cause projects to fail

* Telecommuting is bad (I do it - I like it)

* Telecommuting projects will fail (D'oh - of course not)

* You shouldn't telecommute (of course you should if you want to - but bear in mind that the business may have good reasons to disagree with that decision)

* That telecommuting makes you individually less productive (I'm personally unsure about this. I feel more productive when working by myself, but I know that personal perceptions of productivity can be false. Measuring personal vs team/company productivity becomes hard in anything less than the short term)

* That co-location is always the best solution (it isn't - other factors like team location and skills come into play)

What I am saying is that there is a lot of research showing that co-located teams in team-room like settings are much more productive. This runs counter to many developers preferences (mine too ;-) so it tends to get ignored.

So much more productive that solutions like 'Let's fly everybody to the same place and pay their room and board for a month' can be cost effective.

Here are some references to the research (If anybody has any research that contradicts this I'd love to hear about it. Especially if it talks about actual measured metrics of productivity - rather that self-reported 'I felt just as productive at home' ones.)

----

"It doesn't take much distance before a team feels the negative effects of distribution - the effectiveness of collaboration degrades rapidly with physical distance. People located closer in a building are more likely to collaborate (Kraut, Egido & Galegher 1990). Even at short distances, 3 feet vs. 20 feet, there is an effect (Sensenig & Reed 1972). A distance of 100 feet may be no better than several miles (Allen 1977). A field study of radically collocated software development teams,[...], showed significantly higher productivity and satisfaction than industry benchmarks and past projects within the firm (Teasley et al., 2002). 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). Close proximity improves productivity in all cases." -- http://conway.isri.cmu.edu/~jdh/VRC-2008

"Based on the empirical evidence, we have constructed a model of how remote communication and knowledge management, cultural diversity and time differences negatively impact requirements gathering, negotiations and specifications. Findings reveal that aspects such as a lack of a common understanding of requirements, together with a reduced awareness of a working local context, a trust level and an ability to share work artefacts significantly challenge the effective collaboration of remote stakeholders in negotiating a set of requirements that satisfies geographically distributed customers" -- http://link.springer.com/article/10.1007%2Fs00766-003-0173-1

"Our results show that, compared to same-site work, cross-site work takes much longer and requires more people for work of equal size and complexity. We also report a strong relationship between delay in cross-site work and the degree to which remote colleagues are perceived to help out when workloads are heavy" -- http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?reload=true&#...

"Our findings reveal that: software developers have different types of coordination needs; coordination across sites is more challenging than within a site; team knowledge helps members coordinate, but more so when they are separated by geographic distance; and the effect of different types of team knowledge on coordination effectiveness differs between co-located and geographically dispersed collaborators." -- http://kraut.hciresearch.org/sites/kraut.hciresearch.org/fil...

"One key finding is that distributed work items appear to take about two and one-half times as long to complete as similar items where all the work is colocated" -- http://www.computer.org/portal/web/csdl/doi?doc=doi/10.1109/...

"Our study of six teams that experienced radical collocation showed that in this setting they produced remarkable productivity improvements. Although the teammates were not looking forward to working in close quarters, over time they realized the benefits of having people at hand, both for coordination, problem solving and learning.Teams in these warrooms showed a doubling of productivity" -- http://possibility.com/Misc/p339-teasley.pdf

"Despite the positive impact of emerging communication technologies on scientific research, our results provide striking evidence for the role of physical proximity as a predictor of the impact of collaborations." -- http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjourna...

"Groups with high common ground and loosely coupled work, with readiness both for collaboration and collaboration technology, have a chance at succeeding with remote work. Deviations from each of these create strain on the relationships among teammates and require changes in the work or processes of collaboration to succeed. Often they do not succeed because distance still matters" -- http://dl.acm.org/citation.cfm?id=1463019

The "everybody has bugs" response is intellectually dishonest. Yes, everybody has bugs, but most people's bugs aren't an intentional feature that a trained monkey ought to have known was a bad idea.

- Someone implemented a YAML parser that executed code. This should have been obviously wrong to them, but it wasn't.

- Thousands of ostensible developers used this parser, saw the fact that it could deserialize more than just data, and never said "Oh dear, that's a massive red flag".

- The bug in the YAML parser was reported and the author of the YAML library genuinely couldn't figure out why this mattered or how it could be bad.

- The issue was reported to RubyGems multiple times and they did nothing.

This isn't the same thing as a complex and accidental bug that even careful engineers have difficulty avoiding, after they've already taken steps to reduce the failure surface of their code through privilege separation, high-level languages/libraries, etc.

This is systemic engineering incompetence that apparently pervades an entire language community, and this is the tipping point where other people start looking for these issues.