What Makes Some Interruptions More Disruptive Than Others?

Factors such as time of day and interruption source can cause interruptions to be more disruptive.

This is the latest issue of my newsletter. Each week I cover the latest research and perspectives on developer productivity.

---

This week I read Task Interruption in Software Development Projects: What Makes some Interruptions More Disruptive than Others? by researchers from the University of Calgary in Canada. This study sheds light on the factors that make certain interruptions more disruptive to developers than others, as well as the types of development work that are more vulnerable to task switching. 

My summary of the paper

Task switching is an unavoidable part of software development: while working, developers may get questions from their colleagues that interrupt their work, they may receive priority changes, or they may get sidetracked. Prior studies have explored the costs of such interruptions in terms of “resumption lag” (it takes 15-30 minutes for developers to resume to their original task after an interruption), and increased error rates. 

Before this study, researchers hadn’t yet explored what makes certain task interruptions more disruptive than others. To investigate, researchers conducted a mixed-methods study. This included a longitudinal data analysis that explored the disruptiveness of different factors, such as the type of interruption and the timing of the interruption. Then, researchers conducted a survey amongst professional software developers from different organizations to learn more about the reasons for these interruptions. 

In this study, the authors define task switching as “the act of starting one task and moving to another before finishing the first.” They consider task switching to be a type of interruption. The disruptiveness of an interruption is measured as a function of time and number of distractors. 

Characteristics that determine how disruptive interruptions are

As part of their study, the researchers explored the factors that may explain the disruptiveness of interruptions in various types of software development tasks.

Notes for reading the table below:

• We can see the interruption characteristics grouped into two categories. Context-specific factors include whether the primary and secondary task are related to the same project, are of the same type (architecture design, programming, etc.), the interruption’s source, and when the interruption happens (morning, afternoon). Task-specific factors include whether the primary and secondary task are of the same priority, the developers’ level of experience, the task level, and stage of completeness. 

• We can also see the task types: architecture design (Arch), programming (Prog), testing (Test), UI design (UI), and deployment tasks (Dep). 

• Filled-in circles show us where the interruption characteristics make interruptions more disruptive for specific task types. 

• [∆] denotes the length of time of an interruption, and [|w|] denotes the number of nested interruptions. 

1. When compared to task-specific factors, contextual factors are generally stronger predictors of how disruptive an interruption will be. Contextual factors include the time of day when an interruption happens, whether the interruption was caused by the developer themselves or by something external, and whether the interruption included context switching (switching from one type of task to a different type of task). Task-specific factors include whether the original task and new task are of the same or different priority, the developers’ level of experience (in years), and the completion stage of the original and new task. 

2. Self-interruptions cause task switches that take more time and involve a higher number of distractors, however developers reported external interruptions to be more disruptive. Self-interruptions originally appeared to be more disruptive, but the researchers’ follow-up interviews found that developers perceive external interruptions to be more painful. One possible reason for this is because external interruptions are not expected and therefore not in developers’ control. Still, the authors suggest that developers aim to minimize self-interruptions and voluntary task switching. 

The types of work that are more vulnerable to task switching 

This study also found that programming and testing tasks are more vulnerable to task switching and interruption. They write that “this finding is consistent with [prior experimental evidence]… which shows that solving problems requiring a large number of items be stored in human short-term memory may contribute to excessive cognitive load.” 

Due to the problem-solving nature of programming and testing tasks, and knowing that human short-term memory cannot accommodate a large number of items, the researchers recommend that developers minimize task switching when working on programming and testing tasks.

Final thoughts

Many teams struggle to get enough time for deep work, but this is a fairly well-known problem. While much of the advice surrounding deep work focuses on no-meeting days or getting developers to group similar types of tasks together, this paper offers new ways to think about solving the problem. Leaders looking to increase their teams’ time for uninterrupted work may pull ideas from this paper: for example, teams might be more cognizant about interruptions in the afternoon, and leaders may encourage developers to focus on one project at a time to reduce self-interruptions. 

---

That’s it for this week! If you’re interested in more research, send me a connection request with the note “research” and I’ll share a downloadable bundle of my top 10 favorite papers of this year.

-Abi