Content uploaded by Alexey Tregubov
Author content
All content in this area was uploaded by Alexey Tregubov on Aug 21, 2020
Content may be subject to copyright.
Impact of Task Switching and Work Interruptions on Soware
Development Processes
Alexey Tregubov
University of Southern California
941 W 37 Pl, SAL 327
Los Angeles, California 90089-0781, USA
tregubov@usc.edu
Barry Boehm
University of Southern California
941 W 37 Pl, SAL 328
Los Angeles, California 90089-0781, USA
boehm@usc.edu
Natalia Rodchenko
University of Southern California
1050 Childs Way, RRI 316B
Los Angeles, California 90089-0781, USA
rodchenk@usc.edu
Jo Ann Lane
San Diego State University
5500 Campanile Drive
San Diego, California 92182-7720, USA
jalane@mail.sdsu.edu
ABSTRACT
Software developers often work on multiple projects and tasks
throughout a work day, which may aect their productivity and
quality of work. Knowing how working on several projects at a time
aects productivity can improve cost and schedule estimations. It
also can provide additional insights for better work scheduling and
the development process. We want to achieve a better productivity
without losing the benets of work interruptions and multitasking
for developers involved in the process. Tounderstand how the devel-
opment process can be improved, rst, we identify work interrup-
tions that mostly have a negative eect on productivity, second, we
need to quantitatively evaluate impact of multitasking (task switch-
ing, work context switching) and work interruptions on productiv-
ity. In this research we study cross-project multitasking among the
developers working on multiple projects in an educational setting.
We propose a way to evaluate the number of cross-project inter-
ruptions among software developers using self-reported work logs.
This paper describes the research that found: a) software developers
involved in two or more projects on average spend 17% of their
development eort on cross-project interruptions, b) the amount of
eort spent on interruptions is overestimated by the G. Weinberg’s
heuristic, c) the correlation between the number of projects and
eort spent by developers on cross-project interruptions is rela-
tively weak, and d) there is strong correlation between the number
of projects and the number of interruptions developers reported.
CCS CONCEPTS
•Social and professional topics →Software management
;
•
Software and its engineering →Programming teams;
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for prot or commercial advantage and that copies bear this notice and the full citation
on the rst page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specic permission and/or a
fee. Request permissions from permissions@acm.org.
ICSSP’17, Paris, France
©2017 ACM. 978-1-4503-5270-3/17/07. . . $15.00
DOI: 10.1145/3084100.3084116
KEYWORDS
Work interruptions, eort estimation, multitasking overhead, cost
estimation, software development
ACM Reference format:
Alexey Tregubov, Barry Boehm, Natalia Rodchenko, and Jo Ann Lane. 2017.
Impact of Task Switching and Work Interruptions on Software Development
Processes. In Proceedings of 2017 International Conference on Software and
Systems Process , Paris, France, July 2017 (ICSSP’17), 5 pages.
DOI: 10.1145/3084100.3084116
1 INTRODUCTION
Many have observed that software developers need to switch be-
tween dierent tasks quite often throughout a work day [1]. Parnin
and Rugaber [1] studied 10,000 sessions of developers’ work and
concluded that work interruptions and task resumptions are a
frequent problem for developers. Another study [7] found that
information-technology workers spent an average of only 3 min-
utes per task before switching to another task. DeMarco and Lis-
ter [3] found that developers work only 30% of their time alone
and spend another 70% on collaboration and interaction with each
other. Often such collaboration introduces work interruptions and
requires developers to work on several projects at a time. In general,
working on multiple tasks at a time and switching between them
can have both positive and negative eects.
In order to better estimate development costs and achieve a better
productivity we want to know the negative impact of work inter-
ruptions. We chose to study cross-project interruptions, because
this type of interruptions introduces a time-consuming context
switching which is often viewed as a waste of time. To achieve a
better productivity cross-project interruptions can be reduced in
development processes (e.g. Lean, Agile processes).
In this research, we quantitatively evaluated the impact of cross-
project context switching and work interruptions on cost overhead
in several software development projects in an educational setting.
We used observational data collected from developers’ self-reported
work logs.
We answer two research questions in this study: (1) whether
there is a linear correlation between the number of cross-project
work interruptions and the number of projects and (2) whether
134
ICSSP’17, July 2017, Paris, France Alexey Tregubov, Barry Boehm, Natalia Rodchenko, and Jo Ann Lane
Figure 1: Reimmersion time.
there is a linear correlation between the amount of time spent on
cross-project interruptions and the number of projects involved.
2 BACKGROUND
Dzubak [4] denes multitasking as the engagement in individual
tasks that are performed sequentially and implies that there is
necessarily some time spent switching between tasks. In other
words, parallel tasks interrupt each other.
Jett and George [5] distinguish four major types of interruptions:
intrusion, break, distraction, discrepancy. All of them have pos-
itive and negative eects on productivity, dierent resumptions
time, dierent time of switching to a new work context, dierent
underlining causes and sources of interruptions.
Positive eects of work interruptions in software development
include a better team collaboration and communication (e.g. inter-
ruptions for design/peer review and architecture review meetings,
which help developers to dene a “big picture” of the project and
obtain a feedback from their colleagues [4]), a stimulating work
environment (e.g. reduced “the boredom eect” and the inclination
to procrastinate [4]), a reduced “struggle time” trying to solve com-
plex problems for too long [6]. Positive interruptions are typically
related to software design work, problem solving, and debugging
activities that often depend upon the creation and evolution of
mental models. These mental models are what facilitate concurrent
engineering and development.
Along with positive eects, studies [7-8] found that multitasking
can reduce work productivity. In particular, interruptions introduce
necessary time spent switching between the tasks, called “attention
switching” in [8] and make an individual less productive by reduc-
ing the amount of short-term memory dedicated to a single task.
Salvucci et al. [9] performed a set of experiments and observations
to measure the time cost of task switching and determined that it
depends on the complexity of the task, time length between task
switches, and causes of interruptions (e.g. external or self-inicted
interruptions).
DeMarco and Lister [7] introduced a metric called reimmersion
time as a measure of the eect of task interruption. Reimmersion
time is an extra eort to complete the task after an interruption
(Fig. 1). This metric is also known as resumption lag [1, 7, 9, 10].
G. Weinberg [11] introduced a heuristic measure of the eect of
multitasking on reimmersion time that is a simple linear function
of the number of projects assigned to an individual at the same time
(see Fig. 6). The heuristic predicts a 100% increase of multitasking
overhead for every additional task assigned.
In this paper, we study only cross-project interruptions and
cross-project multitasking. We dene cross-project multitasking
as an involvement of software developers in multiple engineering
activities with dierent or minimally overlapping contexts over
a certain period. Cross-project interruptions are characterized by
relatively long reimmersion times, longer resumption times, and
signicantly dierent work contexts of interrupting tasks [9]. Of-
ten such interruptions are external (not self-inicted); therefore,
could be limited by the development process (e.g. Agile and Lean
development processes acknowledge the problem and introduce
measures to reduce work interruptions [12, 13]).
Cross-project multitasking and interruptions may appear in dif-
ferent forms. A few examples are:
–
Developers are often shared between projects in organiza-
tions with matrix structure
–
Developers are shared between multiple releases within a
single project (if several releases are maintained)
–
In System of Systems environments, developers are often
shared between several contexts such as customer-specic
requirements, software releases for clients, etc.[13].
The focus of the rest of this paper is on negative productivity
impacts of cross-project multitasking and interruptions.
3 CROSS-PROJECT MULTITASKING AND
INTERRUPTIONS
3.1 Research Questions
In this paper, we measure a negative impact of cross-project inter-
ruptions as the total eort (person-hours) each developer spends
on reimmersion time after each interruption that was caused by
tasks from other activities.
The following research questions are addressed in the analysis
below: is there a linear correlation between the number of projects
each developer was involved with and
a
the number of cross-project interruptions they experience?
b
the amount of eort spent on cross-project interruptions?
There were two types of hypotheses tested for each question:
H.1
Correlation between subject means: developers working
on more projects tend to experience more cross-project (a)
interruptions, (b) spent more eort.
H.2
Correlation within subjects: an increase of the number of
projects per subject is associated with an (a) increase of
the number of cross-project interruptions, (b) increase of
time spent on interruptions.
Additionally, we also compared the eort evaluation results with
the predictions of G. Weinberg’s heuristic (Fig. 6).
3.2 Data Collection
In order to evaluate the impact of cross-project multitasking, we
observed 10 software projects for three months. All projects were
developed as part of a graduate level software engineering class at
the University of Southern California. Clients of these projects rep-
resent various non-prot organizations, entrepreneurs and private
companies. Clients joined teams of students of software engineer-
ing class to work on their projects. Most of the projects were scoped
135
Impact of Task Switching and Work Interruptions on Soware Development Processes ICSSP’17, July 2017, Paris, France
to t into a single semester of the class. Working on real life projects
and reporting project progress is part of the class curriculum.
In total, we collected work logs and weekly progress reports of
68 students for one semester of work. All students had degrees in
computer science related elds and experience in software devel-
opment.
Daily work logs were part of the work process, which allowed us
to collect data on development eort and acquire development eort
distribution across projects and individuals without interfering with
their work ow. Project tasks were assigned to developers via the
project tracking system used in the class. Every student reported
their daily and weekly progress (time spent) on each task, that
he/she performed on that day. In addition to the work logs, students
also provided weekly information about work interruptions and self-
evaluated reimmersion time. They were instructed how to evaluate
their reimmersion time and how to use the project tracking system.
Some of the students also took one or two other classes and
had no outside jobs; therefore, they had to distribute their time
between the following three types of activities: (1) a project in the
software engineering class, (2) group projects/tasks/assignments
in classes other than the software engineering class, (3) individual
assignments in the software engineering class and all other classes.
These three types of activities have very dierent context of work,
and independent deadlines. We viewed a switching between these
three types of activities as a cross-project interruption.
In this study, we collected detailed information about projects
in the software engineering class via the project tracking system
(Atlassian Jira). The project tracking system tracked tasks’ statuses.
A task’s status, reported by developers, can show if it is completed,
in progress or in the backlog. A task’s labels also allowed us to
distinguish dierent types of engineering activities (requirement
engineering, coding, testing, documentation, etc.).
We collected information about the impact on the class project
from the other two types of activities via weekly progress reports,
where students provided self-evaluated reimmersion time and types
of activities they were involved with throughout the week.
For the purpose of consistent terminology in this paper, we will
call the three types of activities listed above as projects (activi-
ties with dierent context of work). We also will count switching
between them as cross-project switching.
In order to analyze the impact of interruptions on eort, we
selected a subset of 29 full-time students who worked in similar
conditions. They only took two classes (one of them was the soft-
ware engineering class) and had no outside jobs. At least 25% of their
time in the class project was dedicated to development activities
(programming, bug xing, etc.).
3.3 Calculation of Work Interruptions and
Reimmersion Time
We used reimmersion time as described in Fig. 1 to evaluate the
impact of cross-project interruptions on developers’ productivity.
In order to calculate the total eort each developer spends on reim-
mersion, we need to know the number of interruptions (obtained
from work logs) and the reimmersion time after each interruption
(evaluated by developers).
Work interruptions were counted by analyzing developers’ work
logs and weekly progress reports. These two sources of information
were used to verify the information about the number of projects
students were involved with and the number of interruptions they
experienced. Weekly progress reports provide the number of inter-
ruptions evaluated by developers, and work logs allow us to see
how developers worked on a software engineering class project
throughout the week. Since all 29 developers spent their work time
only on up to three projects at a time (including the software engi-
neering class project), their work logs of tasks from the software
engineering class projects showed when work was interrupted. In
some cases work logs can only provide a lower bound estimate on
the number of interruptions, because we were only able to track
one out of three projects they worked on.
Reimmersion time may depend on many factors: the complexity
of the task, length of the interruption, complexity of the other task
that interrupted work, individual’s personality (closure-oriented
vs. curiosity-oriented), etc.[5]. To account for all the factors that
impact the reimmersion time we asked developers to evaluate their
weekly average reimmersion time for tasks that they did for the class
project. The total weekly eort spent on cross-project interruptions
(i.e. multitasking overhead) is computed as the total number of
interruptions times the reimmersion time.
4 RESULTS
In our observational data we collected repeated measures for the
same set of projects over the course of 12 weeks (12 weeks = 12
times); therefore, we had to account for repeated observations in
our linear regression analysis. For both eort and interruptions we
tested two types of hypotheses: (1) developers working on more
projects tend to have more interruptions and tend to spend more
eort on multitasking overhead; (2) the increase of the number of
projects worked on is associated with increase of the number of
interruptions and eort.
To answer the rst group of questions we used the linear cor-
relation between subject means (mean values of the number of
projects each developer was involved in, eort and the number
of cross-project interruptions of each developer). Fig. 2 shows the
correlation between the average number of interruptions and the
average number of projects per week per developer. The total num-
ber of data points is 29. The linear correlation is relatively strong
(R2 = 0.60699). It supports the hypothesis H1.a that developers
working on more projects tend to experience more interruptions.
Fig. 3 shows the correlation between the average eort spent on
context switching (cross-project multitasking overhead) and the
average number of projects per week per developer. The total num-
ber of data points is also 29. The linear correlation is weak (R2 =
0.1622). It does not support the hypothesis H1.b that developers
working on more projects tend to have more cross-project multi-
tasking overhead. From Fig. 6 we can see that average multitasking
overhead remains the same.
To answer the second group of questions we used a multiple
linear regression analysis to compute correlation coecients. We
treated developers as a categorical factor (a predictor). Fig. 4 shows
the number of interruptions versus the number of projects per
week. The total number of data points is 348 (repeated observations
136
ICSSP’17, July 2017, Paris, France Alexey Tregubov, Barry Boehm, Natalia Rodchenko, and Jo Ann Lane
Figure 2: The average number of interruptions vs. the aver-
age number of projects per week per developer.
Figure 3: The average eort (person hours) vs. the average
number of projects per week per developer.
included). The linear correlation is strong (multiple R2 = 0.7779). It
supports the hypothesis H2.a. This means that when a developer
works on three projects in one week, he/she experiences more inter-
ruptions compared to weeks when he/she works on two projects. If
developers work on one project, there is no cross-project interrup-
tions at all. Fig. 5 shows the eort spent on context switching versus
the number of projects per week. The total number of data points
is 348 (repeated observations included). The linear correlation is
strong (multiple R2 = 0.6934). It supports the hypothesis H2.b It
means that when a developer works on three projects in one week,
he/she has more multitasking overhead compared to weeks when
he/she works on two projects.
To better see how multitasking overhead aects productivity, we
converted eort spent on cross-project interruptions (measured in
person hours) into the percentage of the full-time equivalent (FTE).
FTE = 40 person hours per week.
Fig. 6 shows average eort each developer spent on cross-project
multitasking overhead per week. It also compares multitasking over-
head results from observations with the G. Weinberg’s heuristic,
which predicts a larger multitasking overhead.
Figure 4: The number of cross project interruptions vs. the
number of projects per week per developer.
Figure 5: Eort spent on context switching vs. the number
of projects per week per developer.
Figure 6: Average eort developers spent on cross-projects
multitasking per week as a portion of FTE.
Dierent sources estimate that the reimmersion time for infor-
mation/knowledge workers varies from 20 minutes to 1-2 hours [1,
2, 7, 9]. We evaluated a lower bound estimate for the multitasking
overhead using a constant 0.5 hour value of the reimmersion time
for all interruptions (see Fig. 6). The evaluated lower bound under-
estimates the actual average value of the multitasking overhead.
Additionally, we wanted to see if there was any impact of cross-
project multitasking on quality of work. Students were evaluated
during architecture reviews meetings and by the clients at the end
137
Impact of Task Switching and Work Interruptions on Soware Development Processes ICSSP’17, July 2017, Paris, France
Figure 7: Quality of work decrease depending on multitask-
ing overhead.
Table 1: Hypotheses summary.
Hypothesis R2/ multiple R2p Accepted / Rejected
H1.a 0.60699 <0.01 Accepted
H2.a 0.7779 <0.01 Accepted
H1.b 0.0.1622 <0.03 Rejected
H2.b 0.6934 <0.01 Accepted
of the semester. The impact on the quality of work was measured
in terms of grade points deducted. Fig. 7 shows grade deduction
depending on the amount of multitasking overhead.
In order to make quantitative conclusions about correlation be-
tween the quality of work and the amount of multitasking overhead,
we need to collect more data. However, visual observation of the
data points suggests that projects where multitasking overhead
took less than 40% of the overall eort had a better quality of work
compare to other projects. Table 1 summarizes all other results.
5 TREATS TO VALIDITY
This is an on-going research which has limitations discussed below.
Self-tracking of the reimmersion time and hours devoted to
projects may not be accurate. However, these values do not af-
fect our conclusions about the correlation between the number of
projects and the number of interruptions. To get a more accurate
evaluation of the reimmersion time, we plan to conduct a more
controlled experiment.
Counting only cross-project interruptions might underestimate
the overall multitasking overhead caused by internal (within project)
and self-inicted interruptions. Therefore, evaluations presented
here can be viewed as a lower bound of the overall multitasking
overhead.
Participating subjects were graduate students in software engi-
neering educational environment. To limit the impact of deadlines
in other classes, students in the selected sample were enrolled in
the same classes (e.g. students who took 3 classes were all enrolled
in software engineering class, algorithms class and AI class). The
method used in this research can be applied to industry projects in
other domains.
6 CONCLUSIONS
In this study, we evaluated the impact of cross-project multitask-
ing on software development eort by analyzing work logs and
weekly progress reports. Results show that developers who work
on 2 or 3 projects spend on average 17% of their eort on context
switching between tasks from dierent projects. Developers who
were involved in more projects tend to have more cross-project
work interruptions. However, the linear correlation between the
number of projects each developer worked on in one week and the
amount of eort developers spend on context switching is weak.
This partially can be explained by excessive amount of switching
between two most active projects.
The number of interruptions can be used successfully to evaluate
the quantitative impact of multitasking on eort. The number of
interruptions that people experience can also be used as a metric
and a measure of multitasking in teams. Additionally, the impact
of multitasking on eort can be integrated into software develop-
ment parametric cost and schedule estimation models such as the
Constructive Cost Estimation Model (COCOMO
©
) for better eort
estimation.
Finally, the work log analysis tools that we used in our research
can be integrated with project tracking systems such as Atlassian
Jira to provide real-time information about work interruptions and
their impact on productivity.
REFERENCES
[1]
Parnin, Chris, and Spencer Rugaber. "Resumption strategies for interrupted pro-
gramming tasks." Software Quality Journal 19, no. 1 (2011): 5-34.
[2]
González, Victor M., and Gloria Mark. "Constant, constant, multi-tasking crazi-
ness: managing multiple working spheres." In Proceedings of the SIGCHI confer-
ence on Human factors in computing systems, pp. 113-120. ACM, 2004.
[3]
DeMarco, Tom, and Tim Lister. Peopleware: productive projects and teams.
Addison-Wesley, 2013.
[4] Dzubak, Cora M. "Multitasking: The good, the bad, and the unknown." The Journal
of the Association for the Tutoring Profession 1.2 (2008): 1-12.
[5]
Jett, Quintus R., and Jennifer M. George. "Work interrupted: A closer look at the
role of interruptions in organizational life." Academy of Management Review 28.3
(2003): 494-507.
[6]
Whittaker, Steve, David Frohlich, and Owen Daly-Jones. "Informal workplace
communication: What is it like and how might we support it?." Proceedings of
the SIGCHI conference on Human factors in computing systems. ACM, 1994
[7]
Meyer, A.N., Fritz, T., Murphy, G.C. and Zimmermann, T., 2014, November. Soft-
ware developers’ perceptions of productivity. In Proceedings of the 22nd ACM
SIGSOFT International Symposium on Foundations of Software Engineering (pp.
19-29). ACM.
[8] Delbridge, Kerry Allison. Individual dierences in multi-tasking ability: Exploring
a nomological network. 2000.
[9] Salvucci, Dario D., Niels A. Taatgen, and Jelmer P. Borst. "Toward a unied theory
of the multitasking continuum: from concurrent performance to task switching,
interruption, and resumption." In Proceedings of the SIGCHI conference on human
factors in computing systems, pp. 1819-1828. ACM, 2009.
[10]
Katidioti, Ioanna, Jelmer P. Borst, and Niels A. Taatgen. "What happens when we
switch tasks: Pupil dilation in multitasking." Journal of experimental psychology:
applied 20, no. 4 (2014): 380.
[11]
Weinberg, Gerald M. "Quality software management." New York (1993).
[12]
Tregubov, Alexey, and Jo Ann Lane. "Simulation of Kanban-based Scheduling
for Systems of Systems: Initial Results." Procedia Computer Science 44 (2015):
224-233.
[13]
Tregubov, Alexey, and Jo Ann Lane. "What does it mean to be Lean in SoSE
environment?." In INCOSE International Symposium, vol. 26, no. 1, pp. 1347-1358.
2016.
138
