The recovery time for a phone interruption is at least 15 minutes. The recovery interruption from an email interruptions is 64 seconds (they measured this by videotaping user sessions using VNC). 70% of users reacted to a new message indicator within 6 seconds of seeing it (almost as fast as a telephone call), 80% reacted within 2 minutes of seeing the indicator.

The frequency of e-mail interrupts is far higher than telephone interrupts (at least for their subjects), meaning that the 64 second recovery time is multiplied by the number of such interruptions.

The recommendations of the study are to turn off sound and pop up new mail alerts, and to change the e-mail checking interval to no less than every 45 minutes.

These are really good recommendations for general usage. Of course, there are times when you really need to buckle down, in which case I pick specific times to check mail, and exit from the mail reader after each session. There are other times, when you are e-mail centric, in which case, you can check the relevant mail folders more frequently. It would be nice to be able to set the poll frequency on a per folder basis...

In the open source world, this is often described under the "release early, release often" mantra. But it's not always followed in the open source world. So you have projects that go long periods of times without a release, where users are told to pull the latest from CVS (hello Jakarta Commons!). That makes it hard to have confidence in the project or to have the project move forward. I think that open source projects should try to do regular time-boxed releases, cutting features in order to make the release dates. There can be exceptions for features that are bigger than a single time-box, but these ought to be the exception rather than the rule. Predictability is good when you are a software user. It makes me feel better when I see that a project releases regularly. Nightly builds are good, but for a lot of projects, I could see semimonthly or monthly time-boxes working pretty well.