Programmers have fought against environments prone to interruption for decades (see Peopleware and Joel Spolsky), but Chris Parnin’s is the first empirical observational research into the effects of interruption that I’ve seen (there are probably others, I’m just more familiar with the anecdotal evidence). His approach of using automatically collected data is really interesting:
We draw upon a variety of data sets in our analysis. The first data set we will call the Eclipse data set; it was originally collected in the latter half of 2005 by Murphy et al. (2006). The researchers used the Mylyn Monitor tool to capture and analyze fine-grained usage data from volunteer programmers using the Eclipse development environment.
The Visual Studio data set was collected in 2005 by Parnin and Görg (2006) at an industrial site. The previously published data included ten developers for 30 work days (1.5 months). Since the original publication, the data we report in this paper also includes two more developers and a few more months of data.
The UDC dataset is publicly available from the Eclipse Usage Data Collector (2009) and includes data requested from every user of the Eclipse Ganymede release. Activity is recorded from over 10,000 Java developers between April and December 2008. The data counts how many programmers have used each Eclipse command, such as navigations or refactoring commands, and how many times each command was executed.
To obtain the developer’s sessions, the events were segmented when there was a break in activity of 15 min or more.
On Hacker News, user grecy comments on a strategy one of his former employers used to minimize interruptions for programmers:
At my last company us developers complained that we were getting interrupted too much, so the boss asked us to keep a list of interruptions. By lunch on the first day we all had 3+ pages, so he believed us and we implemented the following:
Each week, one pair of programmers would be designated the “consulting developers”, and a big sign would be put above their desk. They were the only developers that could be interrupted for the week, allowing the rest of us to get a lot of work done. If the consulting developers needed to ask something of other developers, we tried to save it up for lunch, as we mostly all ate together anyway.
This made an enormous difference to our productivity, which everyone in the company took notice of when the number of “development days” we got done each week increased dramatically.
At the start we thought of “sacrifice one for the good of all” and we didn’t look forward to our turn. As time went on it actually turned out differently. We usually enjoyed the “consulting” time as it meant a break from the routine of working on endless tickets, and it also kept us in touch with what the rest of the company was doing with regards to deploys, environments, configs, etc. etc.
This strikes me as an excellent idea to limit the problems with interruptions. The “on call” developers could help handle support requests, too.