MasterThesis PDF

Master Thesis
June 19, 2014

Personal Analytics
Two Studies on Software Developers
Perceptions of Productivity
Andr Meyer
of Uster, Switzerland (09-736-398)
supervised by
Prof. Dr. Thomas Fritz
software evolution & architecture lab
Master Thesis
Personal Analytics
Two Studies on Software Developers
Perceptions of Productivity
Andr Meyer
software evolution & architecture lab
Master Thesis
Author: Andr Meyer, info@andre-meyer.ch
URL: www.andre-meyer.ch
Project period: 01/14/2014 - 07/14/2014
Software Evolution & Architecture Lab
Department of Informatics, University of Zurich
Acknowledgements
I would like to thank all the people who were involved in this thesis. First of all, I thank Prof.
Dr. Thomas Fritz for giving me the opportunity to write this thesis at the software evolution and
architecture lab (s.e.a.l.) and for his excellent support. Moreover, I want to thank Prof. Dr. Gail
Murphy (University of British Columbia) and Dr. Thomas Zimmermann (Microsoft Research) for
their valuable comments, suggestions, help, and ideas. Further appreciation goes to the members
of the s.e.a.l. group for always being open for a discussion or being pilot participants. I also
would like to express many thanks to my parents, my girlfriend, and my friends who gave me
insights and comments from other non IT-related perspectives and motivated me throughout my
work.
Disclaimer
Parts of this thesis work were worked on in collaboration with Prof. Dr. Gail Murphy (Univer-
sity of British Columbia) and Dr. Thomas Zimmermann (Microsoft Research). In particular, the
chapters on related work (Chapter 2), results for the rst study (Chapter 3), results for the second
study (Chapter 4), and parts of the discussion (Chapter 5). Together we submitted a paper to the
FSE14 conference [MFMZ14], which was accepted in June 2014.
Abstract
The better the software development community becomes at creating software, the more software
the world seems to demand. One way to address the gap between software demand and supply
is to try to increase the supply, by optimizing the productivity of software developers. Although
there is a large body of research about measuring and investigating productivity from an orga-
nizational point of view, there is a paucity of research about how software developers, those at
the front-line of software construction, think about, assess, and try to improve their productivity.
To investigate software developers perceptions of software development productivity, we con-
ducted two studies: a survey with 379 professional software developers to help elicit themes and
an observational study with 11 professional software developers to investigate emergent themes
in more detail. In the survey we found that software developers perceive their days as produc-
tive when they complete many or big tasks, without signicant interruptions or context switches.
Yet, the observational data we collected shows our participants performed signicant task and
activity switching, while still feeling productive.
We analyze such apparent contradictions in our ndings and use the analysis to propose ways
to better support software developers in a retrospection and improvement of their productivity
through the development of new tools and the sharing of best practices. Based on the nding that
there might not be a single and/or simple measurement for a software developers productivity,
we discuss a new idea to provide a software developer with a meaningful retrospective analysis
of his workday and workweek and its possible impact on a developers productivity.
Zusammenfassung
Je besser die Software Entwicklungs-Branche bei der Herstellung von Software wird, desto mehr
Software scheint die Welt zu fordern. Eine Mglichkeit um die Lcke zwischen Software Nach-
frage und Angebot zu verkleinern, ist das Optimieren der Produktivitt von Software Entwick-
lern. Obwohl es eine Vielzahl an aktueller Forschung zum Messen und Untersuchen von Produk-
tivitt aus organisationsorientierter Sicht gibt, gibt es einen Mangel an Forschung die beschreibt,
wie Software Entwickler, jene an der Front des Software Entwicklungs-Prozesses, ber Produktiv-
itt denken, ihre Produktivitt einschtzen, und was sie tun, um ihre Produktivitt zu verbessern.
Wir haben zwei Studien durchgefhrt, um die Auffassung der Produktivitt eines Software En-
twicklers zu untersuchen: Eine Umfrage mit 379 professionellen Software Entwicklern um Leit-
motive zu eruieren, und eine Beobachtungs-Studie mit 11 professionellen Software Entwicklern,
um diese Leitmotive im Detail zu erforschen. In der Umfrage haben wir festgestellt, dass En-
twickler sich produktiv fhlen, wenn sie viele oder grssere Aufgaben ohne erhebliche Unter-
brche und Kontext-Wechsel erfllen knnen. Die in der Observations-Studie erfassten Daten
zeigen, dass Teilnehmer zwar signikante Wechsel zwischen Aufgaben und Aktivitten gemacht
haben, sich aber trotzdem produktiv fhlen.
Wir analysieren diese scheinbaren Gegenstze in unseren Ergebnissen und nutzen die Erken-
ntnisse um Wege aufzuzeigen, wie Software Entwickler besser bei der Retrospektive ihrer Arbeit
und Verbesserung ihrer Produktivitt untersttzt werden knnten. Dazu beschreiben wir beste-
hende und mgliche neue Anwendungen, sowie bewhrte Praktiken unserer Studien-Teilnehmer.
Basierend auf der Erkenntnis, dass es mglicherweise kein einzelnes und/oder einfaches Mass
fr die Produktivitt eines Software Entwicklers gibt, beschreiben wir eine neuartige Idee, um
einem Software Entwickler eine aussagekrftige retrospektive Analyse seines Arbeitstages und
seiner Arbeitswoche anzubieten, und diskutieren mgliche Auswirkungen auf die Produktivitt
des Software Entwicklers.
Contents
1 Introduction 1
2 Related Work 3
3 Study 1: Survey 7
3.1 Participants and Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1 A Productive Workday . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2 Productive and Unproductive Activities . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3 Assessing Productivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.4 Measuring Productivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.5 Inuence of Goal Setting on Productivity . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Study 2: Observations 17
4.1 Participants and Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
x Contents
4.2.3 Work Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.4 Goal Setting and Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Discussion And Future Work 27
5.1 Setting Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Retrospective Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 Reducing Context Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6 Conclusion 39
Contents of the CD-ROM 47
Online Survey Questionnaire 49
Observation Log 55
Interview Protocol 57
Contents xi
List of Figures
3.1 Developers Productivity Satisfaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Metrics for Assessing Productivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Developers Activity and Task Switches in the Two Observation Sessions. . . . . . . . 21
5.1 Overview of a Possible Retrospective Analysis of a Developers Workday. . . . . . . 30
5.2 Design Prototype of a Possible Implementation of the Retrospection Approach. . . . 34
List of Tables
3.1 Sample Survey Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Top 5 Reasons for a Productive Workday. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Top 5 Productive and Unproductive Activities. . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 The Information Participants Want to Measure. . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 How the Participants Monitor their Goals. . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1 Observation Study Participants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Sample Observation Log Entries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Activity Categories for the Observations. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1 Selection of Possible Tracked Measurements for the Retrospection. . . . . . . . . . . . 32
5.2 Possible Higher-Level Measurements for the Retrospection. . . . . . . . . . . . . . . . 33
xii Contents
Chapter 1
Introduction
When you can measure what you are speaking about, and express it in numbers,
you know something about it; but when you cannot measure it, when you cannot
express it in numbers, your knowledge is of a meager and unsatisfactory kind.
Lord Kelvin (William Thomson), 1883.
There is a common refrain that repeats itself in similar forms every few years: the inability for
enough software to be produced to satisfy the needs of the world. In 1968, attendees at the rst
NATO software engineering conference coined the term software crisis [NR69]. In 1972, Dijkstra
wrote about programming [becoming a] gigantic problem [Dij72]. In 1987, Brooks described
how technological improvements can help but will not solve all (essential) problems of software,
as there is no one silver bullet [Bro87]. In the same year, Boehm wrote about the growing demand
for software [Boe87]. In 1996, Gibbs wrote about the chronic software crisis [Gib94]. And in 2011,
Andressen wrote about software eating the world, expressing that the need for software keeps
outstripping the ability to produce the software [And].
There are a couple of ways of addressing the gap between software demand and supply. We
could try to reduce the demand, namely the worlds appetite for software. This approach seems
unlikely to succeed. Or, we could try to increase the supply, namely our ability to produce soft-
ware. In this thesis, we consider one way to address supply: how we might improve the produc-
tivity of software developers.
A substantial amount of research into the meaning of software productivity has been under-
taken over the past four decades (Chapter 2). Much of this research introduces particular de-
nitions of productivity, such as computing productivity based on the number of source lines of
code per hour [DKMT96]. Another body of research considers organizational issues associated
with productivity, such as the effect of the workplace on developer
1
performance [DL85]. There
is also research focused at specic tools and approaches for improving productivity. For exam-
ple, the Personal Software Process (PSP) aims to help software developers improve their skills
and quality of work by tracking a number of measurements, including schedule data [Hum96a].
1
The term developer, participant and user can describe a female or male person. For simplicity reasons the male form
was used throughout this thesis.
2 Chapter 1. Introduction
Surprisingly, there has been no work that we have been able to nd that considers when software
developers perceive themselves to be productive and when they perceive themselves as unpro-
ductive. This information can help inform how productivity is dened, measured, assessed and
supported by tools and best practices.
In this thesis, we investigate developers perception of productivity. In particular, we examine
the following research question:
RQ1 What is software developers perception of productivity and how does it manifest itself in
their work?
To answer this research question, we gather data about software developers perceptions of
productive and unproductive work through two studies: a survey (Chapter 3) and an observa-
tional study (Chapter 4). The survey we conducted had 379 responses from individuals with
an average of 9.2 (7.3) years of professional software development experience. Our analysis of
the survey responses found, amongst other results, that developers think about productive days
in terms of ones in which many small or one big task are completed without signicant context
switching or interruptions.
The observational study we conducted involved observing 11 professional software devel-
opers with an average of 5.4 (3.4) years of professional software development experience from
three companies at work for four hours each. During the developers normal workday, we col-
lected detailed logs of the tasks worked on and the programs used to perform work, gathering a
total of 2650 log entries. We also performed semi-structured follow-up interviews of the partic-
ipants in this study. From this data, we found that signicant context switching between tasks
and activities can occur with developers still perceiving themselves as productive. The number
of task switches we observed, 13.3 (8.5) per hour on average is similar to other reports in the
literature [GM04, KAP
+
07]. The number of activity switches (switches between activities such as
programs or meetings) is larger than reported in previous studies at 47 (19.8) times per hour
on average. From this study, we gained insights into the complexities involved with helping
developers assess their own productivity.
We conclude the thesis with a discussion of ways in which we might help developers retro-
spect upon their productivity, reduce context switches, and share best practices (Chapter 5).
This thesis makes the following contributions:
1. It presents results from a survey of 379 professional software developers, describing their
perceptions of when their work is productive and what measurements of productivity they
might nd useful,
2. it presents the results of an observational study of 11 professional software developers,
showing that productive work can occur in the presence of some kinds of fast context
switches, and
3. it synthesizes the results of these two studies to share best practices and suggest ways in
which we might better support developers in reecting upon their productivity and reduc-
ing context switches.
Chapter 2
Related Work
In this chapter, we analyze and discuss related work with respect to three categories: denitions
of productivity, studies on productivity, and retrospection.
Denition of Productivity Denitions of productivity share characteristics of typically being
about efciency, inputs and outputs. As one example, Card denes productivity as the ratio of
output produced to the resources consumed (input) [Car06]. Often, the unit of input is time-
based. Most research in software engineering denes productivity along similar lines; here are
some examples:
number of modication requests and added lines of code per year [MFH02],
number of tasks per month [ZM10],
number of source lines of code per hour [DKMT96],
number of function points per month [Jon94],
number of lines of code per person month of coding effort [BSVW96],
amount of work completed per reported hour of effort for each technology [KMB
+
96],
ratio of produced logical code lines and spent effort [HA05],
average number of logical source statements output per month over the product develop-
ment cycle [LZ97],
total equivalent lines of code per person-month [NHB11],
resolution time dened as the time, in days, it took to resolve a particular modication
request [CHC08], and
number of editing events to number of selection and navigation events needed to nd where
to edit code [KM06].
In this thesis, we do not attempt to dene productivity for developers, but instead, we investigate
how developers themselves think about productive versus non-productive work.
The majority of the work we could nd about software development productivity focused
on the organizational, not the personal, level. DeMarco and Lister found evidence that char-
acteristics of the workplace and organization have signicant inuence on the performance of
4 Chapter 2. Related Work
programmers [DL85]. Boehm looked at large-scale possibilities for improving outputs, such as
hiring well and using better languages and tools [Boe87]. Blackburn et al. correlated lines of code
per person month to aspects such as program size and team size from survey data collected from
Western Europe, Japan and US, nding that time-to-market correlated with higher productivity,
while larger teams tend to have lower productivity [BSVW96]. Through a systematic literature
review, Wagner and Ruhe distilled a list of the main factors inuencing productivity, separating
them into technical (e.g., product complexity) and soft (e.g., manager capability) factors [WR08].
There are much fewer studies on productivity at the level of an individual developer where
the focus is on the study of productivity, not on the effect of introducing a new tool or process
to improve productivity. One of the few recent studies is by Kamma and Jalote who recorded
and analyzed the screens of highly productive developers (as identied by managers) to identify
characteristics of what makes developers productive when performing model-based testing ac-
tivities. They found differences in the behaviors of the highly productive developers that could
be captured as best practices, such as that high productivity programmers moved all required
information to a common place and avoided referring to multiple documents when writing test
cases.
Studies on Productivity To address the previously described gap between software demand
and supply, one could try to increase the supply, namely our ability to produce software. One way
to address supply is to improve the productivity of software developers, as suggested with many
approaches (e.g., Extreme Programming [BA04], Pair Programming [PSHH04], Getting Things
Done [All03]). A few approaches have been aimed more specically at improving productivity.
The most notable of these is the Personal Software Process (PSP), which aims to help individuals
improve their skills and quality of work by collecting (often manually) a set of basic PSP mea-
surements such as time, size, quality (defects), and schedule data [Hum96a, Hum96b]. Johnson
et al. [JKA
+
03] observed a PSP adoption problem, which they attributed to the high overhead
of PSP-style metrics collection and analysis, and the requirement that PSP users switch between
product development and process recording. To eliminate overhead and context switching, they
introduced Hackystat which fully automates both data collection and analysis. Our work is or-
thogonal to PSP and Hackystat in that we explore what it means to developers to be productive
and how they perceive productivity. This information can inform the design of new tools focused
on aspects of productivity that developers care about the most.
In the last twenty years, an increasing number of studies was conducted about how devel-
opers work. Perry and colleagues paper that collected time diaries from developers and per-
formed direct observation of developers at work to see where they spent their time was one of the
rst [PSV94]. They found that work was typically performed in two hour chunks, progress on a
particular development task could end up being blocked for various reasons, over half of the de-
velopers time was spent in interactive activities other than coding and there were seven unique
personal contacts per day on average. The data we present in this thesis, on the observational
study we performed, also found situations where developers were blocked (also similar to Ko et.
al. [KAP
+
07]), but we saw much less time being spent on any one task. Other observational based
studies have focused on specic areas of development, such as novice programming [BS08], pro-
gram comprehension [RTKM12], software dependencies [dSR08], information needs [KAP
+
07],
and change tasks [SMDV06]. The work we report on in this thesis is unique in considering the
condition under which developers perceive they are productive.
5
One aspect that might have a particularly big impact on a developers productivity are in-
terruptions. A lot of work has been conducted to discuss interruptions, for example the inu-
ence of instant messages [CCH00], alerts and notications [IH07], or the fragmented nature of
tasks [GM04, MGH05] on developers productivity. Researchers found that developers are inter-
rupted more often the earlier it is in the day [MICJ14] and in open plan ofces [DMG11], and that
they are more easily distracted and interrupted, if they are doing boring or rote work [MICJ14].
The two studies we report on in this thesis help describe more general work practices about when
developers see themselves as productive.
Self-Monitoring and Retrospection In his book on persuasive technologies, Fogg describes
how self-monitoring technologies assist people in understanding their behavior and help them to
achieve predetermined goals [Fog03]. This area of persuasive technology and quantied self is
growing within research and industry, which can be seen on the example of the wide adoption of
commercial wearable devices for tracking health- and tness-related activities. Research showed
how activity trackers, such as the FitBit [t], Nike+ Fuelband [fue], or Jawbone Up [jaw], succeed
in encouraging short-termbehavior change, such as taking the stairs or going out more [FHMZ14,
RRMC14], by monitoring ones goals. They found that simple and useful metrics combined with
meaningful visualizations and positive feedback motivated users to maintain activity levels. For
example, the creators of the Nike+ Fuelband tried to abstract the collected data into the notion of
a proprietary Fuel, to indicate the users progress towards the predened goals.
Can the success of these activity trackers be replicated to the area of software engineering? We
found a couple of tools that visualize several metrics tracked of a developers workday, such as
Codealike [cod], RescueTime [res], and the Eclipse Activity Report Statistics [ecl]. They all track
the programs the developer uses on his computer or the actions he takes in the IDE and visualize
them, often on a timeline. None of them supports specifying the measurements that are tracked
or setting a personal goal to observe the progress towards it.
In common with all these forms of measuring and self-monitoring is that they need to of-
fer exibility with the selection on the measurements to be tracked [CHW04], respect privacy
concerns [US08, FHMZ14, TS10], assure the integrity and accuracy of the data [US08, RRMC14,
FHMZ14], and be aware of the fact that many users are dishonest and will try to play the mea-
surements if they know what is measured [US08, BVvD12]. This thesis suggests a new approach
to provide a developer with a retrospection on how work was performed, and might help him to
change his behavior towards improving productivity.
Chapter 3
Study 1: Survey
To gain a broad sense of what productivity means to software developers, how developers assess
their productivity, and to answer our research question, we conducted an exploratory study. The
results of this rst study, an online survey, are presented in this chapter and discussed in chapter
5.
3.1 Participants and Method
The online survey had 28 questions: 8 on the participants background and experience, 7 on per-
ceptions of productivity, 7 on goal setting and monitoring, 3 on techniques for improving and
monitoring productivity, and 3 on the rafe participation and dissemination of results. 16 of the
28 questions had a closed set of answers from which a participant selected, while 12 of the ques-
tions were open-ended. Table 3.1 shows an example of a closed and an open-ended question.
None of the questions were obligatory and a participant was allowed to drop out at any time.
Depending on a participants answers, some questions were ltered and not presented to avoid
asking unnecessary questions. The complete online survey can be found in the Appendix. We an-
nounced the online survey on Twitter and in several big online developer forums, including two
big German-speaking IT news portals.
1
We also advertised within Microsoft, sending a person-
alized email to 1500 Microsoft employees and directing them to a special internal posting of the
survey. To incentivize participants, we held a rafe for the online participants to win two 200 US$
Amazon gift certicates and one for the Microsoft participants to win two 50 US$ Amazon gift
certicates. We ended up with 379 valid responses: 185 from the general advertisements and 194
from within Microsoft. Of the 185 participants that completed the survey from the general adver-
tisement, the majority of the participants were from Germany (32%) and Switzerland (16%). Of
all 379 participants, more than 93.4% of the participants listed their job as software developer; the
remaining 6.6% reported having experience in software development. The average professional
software development experience per participant was 9.2 (7.3) years.
1
heise.de/developer and pocketpc.ch, veried 04/08/14
8 Chapter 3. Study 1: Survey
Table 3.1: Sample Survey Questions.
Q10 Are you satised with your productivity last week? (very unsatised,
unsatised, undecided, satised, very satised)
Q11 How did you assess if you were productive last week?
3.2 Results
We begin by describing when and under what conditions the participants perceived their software
development activities as productive. We then describe how participants think they could assess
or measure their productivity. Finally, the inuence of goal setting on participants productivity
is described.
3.2.1 A Productive Workday
In the survey, we asked each participant to complete the sentence I have a productive workday
when . . . in up to three different ways. Table 3.2 summarizes the top ve reasons mentioned by
participants for having a productive workday. Most participants responded that their workday
is productive when they complete tasks or make progress on tasks, as stated by 192, 53.2%. The
second most mentioned reason for having a productive workday is getting into a ow without
having many context-switches and with having no or few interruptions and distractions (182,
50.4%):
I have a productive workday when I have not been stuck in stupid errors [, when I] could work concentrated
and focused. (Web30)
Different kinds of distractions were described, ranging from interruptions from co-workers ask-
ing questions, phone calls, infrastructure issues, such as waiting for a build to complete, to dis-
rupting background-noise in the ofce. While only a few (8, 2.2%) participants stated that a pro-
ductive workday can include meetings, having no meetings is a reason for a productive workday
for 79 (21.9%) participants. The fourth most often mentioned reason for having a productive
workday is having clear goals and specied requirements (72, 19.9%). 62 (17.2%) participants
responded to have a productive workday when they plan their workday beforehand.
Table 3.2: Top 5 Reasons for a Productive Workday. (#: number of participants, %: percentage of partici-
pants)
I had a productive workday when I . . . # %
. . . complete tasks or goals 192 53.2
. . . have no or few interruptions and distractions 182 50.4
. . . have no meetings 79 21.9
. . . have clear goals and/or the requirements are set 72 19.9
. . . plan my workday beforehand 62 17.2
3.2 Results 9
3.2.2 Productive and Unproductive Activities
Other questions focused on developers perceptions of productivity on a ner-grained level. For
example, we asked participants in two open-ended questions about the activities they consider
particularly productive or unproductive in a workday, as summarized in Table 3.3.
Unsurprisingly, the activities mentioned most frequently as particularly productive were cod-
ing related, including implementing new features, testing, bug xing, and code reviews (236,
71.5%). Despite most participants considering coding activities as productive, some participants
(47, 14.2%) did mention certain unproductive aspects; these participants mostly differentiated be-
tween productive coding activities, such as implementing a new feature, and unproductive ones,
mainly debugging, testing and code maintenance.
Many other activities had mixed responses as to whether they were productive or unproduc-
tive. Most participants (191, 57.9%) think meetings are unproductive and a waste of time. How-
ever, 57 (17.3%) considered formal and informal meetings as productive, particularly when the
meetings include decision making, have a clear focus and goals, improve relationships between
developers, help others, and when all meeting attendees are well-prepared. The main reasons
stated for unproductive meetings were missing goals, lacking a preparation, too many partici-
pants attending the meeting, or going over time.
Participants attitudes towards emails are also mixed. 62 (18.8%) participants considered time
spent on email as unproductive, while a few (10, 3.0%) stated reading and writing emails as a
productive activity. The amount of emails and some inefciencies in using emails as a mean of
communication appear to be reasons contributing to this activity being seen as unproductive:
Tracking and responding to tons of emails [and] email communications going back and forth for days to-
gether with no closure. (MS23)
Table 3.3: Top 5 Productive and Unproductive Activities. (#: number of participants, %: percentage of
participants)
# %
Productive activities
coding (implementing new features, testing, bug xing, code reviews) 236 71.5
meetings 57 17.3
planning 25 7.6
documentation and reports 22 6.7
designing or modeling an architecture (i.e. solution for a programming problem) 18 5.5
Unproductive activities
meetings 191 57.9
emails 62 18.8
unplanned work (solving problems, ghting res, unplanned tasks, randomization) 58 17.6
coding (testing, debugging, maintenance) 47 14.2
documentation and reports 25 7.6
Other activities mentioned as being productive included planning (25, 7.6%), writing doc-
umentation and (administrative) reports (22, 6.7%), modeling or designing an architecture (18,
6.7%), or reading (6, 1.8%). Planning was also seen as an unproductive activity by some (20,
6.0%), as it requires a lot of time and effort without directly making progress on the specic tasks.
Unplanned work, such as solving unexpected problems and ghting res, were mentioned
as being unproductive by 58 (17.6%) of the participants. Other unproductive activities included
some specic coding activities (58, 17.%), documentation and (administrative) reports (25, 7.6%),
waiting for others (24, 7.2%), and surng the web for private social networking or news reading
(17, 5.2%).
0
50
100
150
200
5 = very
sased
4 = sased 3 = neutral 2 = unsased 1 = very
unsased
#

o
f

P
a
r
c
i
p
a
n
t
s
workday
last week
Figure 3.1: Developers Productivity Satisfaction.
3.2.3 Assessing Productivity
When asked to rate their productivity on the previous workday and workweek on a Likert-scale
from 1 (very unsatised) to 5 (very satised), most participants were satised with their work
(see Figure 3.1, median of 4, mean of 3.42). Only a few participants mentioned being very satis-
ed (7.7%) or very unsatised (2.1%). The participants reported assessing their productivity in a
variety of ways. Most (242, 78.1%) assessed their productivity based on the tasks they completed
or made progress on in the past workday or workweek. As task sizes vary, developers often work
on a task for several days or weeks. To reect about their productivity on these bigger tasks, they
either split them into smaller sub-tasks or think about the progress on the task at hand. Several
participants (86, 27.8%) mentioned other measurements, such as lines of code, number of com-
mits, number of bugs found or xed, number of test cases written and code reviews completed
and number of emails sent. 19 (6.1%) of the participants compare different aspects of their work-
day or workweek to assess their productivity, such as the time per task ratio, the executed versus
the planned test cases, or the amount of work they did versus the work they could have done.
Others (43, 13.9%) stated that they use their feelings to assess their productivity:
How I felt about my work. Usually I feel awesome if I was productive, otherwise I feel pretty terrible.
(MS131)
3.2 Results 11
3.2.4 Measuring Productivity
Following the previous questions, we asked participants about which measurements might be
helpful to them to assess their productivity. In particular, we asked participants to rate 23 possible
measurements on a ve point Likert-scale, with 1 - they strongly disagree that the metric would
help them to assess their personal productivity and 5 - they strongly agree. We identied the 23
measurements in an iterative process taking into account related work and responses from our
pilot survey participants. The results are presented in gure 3.2.
The measurement with the highest rating is The number of work items (tasks, bugs) I closed.
with a mean of 3.88 (1.22). This supports our ndings described above that participants assess
their productivity often based on their tasks or work items completed. Overall, the means of all
metrics lie between 2 and 4 with an overall mean of 3.14 (0.35). 16 metrics were rated 3 or higher
while only 7 metrics have values slightly below 3, showing that while the number of work items
closed might be considered helpful by a wide range of participants, there is no single metric
that is considerably better than others to assess a developers productivity, similar to [Car06].
Furthermore, participants usually rated several metrics as helpful, and differed in which metrics
they considered more helpful, suggesting that measuring ones productivity is an individual task
that varies across developers.
To reduce the possibility of suggesting the wrong measurements for the previous question,
we asked participants in an open-ended question what they would want to measure to meet their
goals and improve their productivity. 221 (89.1%) of the participants who answered the question
mentioned one or multiple measurements. Thereof, 57 (25.8%) mentioned two or more mea-
surements, which again underlines that there might not be one single measurement to assess a
developers productivity. The mentioned measurements varied a lot across participants. The top
ve mentioned pieces of information participants wanted to measure are presented in Table 3.4.
67 (27.0%) participants are interested in better knowing how they spend their time on their com-
puter, in meetings, or taking breaks, as well as in comparing their time spent coding with the time
spent in meetings, the time spent on personal tasks and the total work time. Similar to the nd-
ings from previous questions, 44 (17.7%) participants wish they could measure the actual work
done or how they progressed on their tasks. Participants were also interested in the value of their
work: 41 (16.5%) participants mentioned that performing useful, necessary, and interesting work
and having the feeling of being necessary to the team or product is very important. They want to
contribute to the success of a project and want their co-workers to be aware of their skills. Other
measurements mentioned to meet ones goals or to improve ones productivity included the time
per task ratio (39, 15.7%), the number of distractions and interruptions (36, 14.5%), and other
specic metrics from issue trackers, testing tools, and code review tools (29, 11.7%).
27 (10.9%) participants explicitly stated that they would not want to be measured, as they
either think measuring decreases their productivity, have privacy concerns, or think it is not pos-
sible to accurately measure productivity:
I dont think you could measure productivity. If I wrote 1000 lines of codes it could be less productive than
100 lines. Closing one complex ticket could be more productive as closing 10 simple tickets. And the eval-
uation of complexity is very individual. I dont think you could monitor productivity in the IT-business.
I dont build cars on the assembly line and at the end of the day, I cant see how much cars I produced.
(Web82)
0
%
1
0
%
2
0
%
3
0
%
4
0
%
5
0
%
6
0
%
7
0
%
8
0
%
9
0
%
1
0
0
%
T
h
e

n
u
m
b
e
r

o
f

c
o
d
e

e
l
e
m
e
n
t
s

(
e
.
g
.

p
a
c
k
a
g
e
s

o
r

c
l
a
s
s
e
s
)

t
h
a
t

I

c
h
a
n
g
e
d
.
T
h
e

n
u
m
b
e
r

o
f

c
o
d
e

e
l
e
m
e
n
t
s

t
h
a
t

I

c
h
a
n
g
e
d

f
o
r

t
h
e

r
s
t

m
e
.
T
h
e

n
u
m
b
e
r

o
f

l
i
n
e
s

o
f

c
o
d
e

t
h
a
t

I

c
h
a
n
g
e
d

p
e
r

d
a
y
.
T
h
e

n
u
m
b
e
r

o
f

e
m
a
i
l
s

I

w
r
o
t
e
.
T
h
e

n
u
m
b
e
r

o
f

c
o
m
m
i
t
s

I

m
a
d
e
.
T
h
e

n
u
m
b
e
r

o
f

A
P
I

m
e
t
h
o
d
s

I

l
e
a
r
n
e
d

e
a
c
h

d
a
y
.
T
h
e

m
e

t
h
a
t

I

s
p
e
n
t

b
r
o
w
s
i
n
g

t
h
e

w
e
b

f
o
r

p
e
r
s
o
n
a
l

m
a
e
r
s

d
u
r
i
n
g

w
o
r
k
.
T
h
e

m
e

i
t

t
o
o
k

m
e

o
n

a
v
e
r
a
g
e

t
o

r
e
s
p
o
n
d

t
o

e
m
a
i
l
.
T
h
e

n
u
m
b
e
r

o
f

t
e
s
t

c
a
s
e
s

I

w
r
o
t
e

t
h
a
t

s
u
b
s
e
q
u
e
n
t
l
y

f
a
i
l
e
d
.
T
h
e

m
e

t
h
a
t

I

s
p
e
n
t

i
n

e
a
c
h

c
o
d
e

p
r
o
j
e
c
t

o
r

p
a
c
k
a
g
e
.
T
h
e

m
e

i
t

t
a
k
e
s

m
e

o
n

a
v
e
r
a
g
e

t
o

s
i
g
n

o

o
n

c
o
d
e

r
e
v
i
e
w
s
.
T
h
e

n
u
m
b
e
r

o
f

m
e
e
n
g
s

I

a
e
n
d
e
d
.
T
h
e

m
e

t
h
a
t

I

s
p
e
n
t

b
r
o
w
s
i
n
g

t
h
e

w
e
b

f
o
r

w
o
r
k

r
e
l
a
t
e
d

i
n
f
o
r
m
a
o
n
.
T
h
e

n
u
m
b
e
r

o
f

t
e
s
t

c
a
s
e
s

I

w
r
o
t
e
.
T
h
e

n
u
m
b
e
r

o
f

c
o
d
e

r
e
v
i
e
w
s

I
v
e

s
i
g
n
e
d

o
.
T
h
e

m
e

I

s
p
e
n
t

i
n

m
e
e
n
g
s
.
T
h
e

n
u
m
b
e
r

o
f

w
o
r
k

i
t
e
m
s

I

c
r
e
a
t
e
d
.
T
h
e

n
u
m
b
e
r

o
f

w
o
r
k

i
t
e
m
s

I

c
r
e
a
t
e
d

t
h
a
t

w
e
r
e

x
e
d
.
T
h
e

n
u
m
b
e
r

o
f

c
o
d
e

r
e
v
i
e
w
s

I
v
e

c
o
n
t
r
i
b
u
t
e
d

t
o
.
T
h
e

m
e

t
h
a
t

I

s
p
e
n
t

w
r
i
n
g

c
o
d
e
.
T
h
e

m
e

I

s
p
e
n
d

r
e
v
i
e
w
i
n
g

c
o
d
e
.
T
h
e

m
e

I

h
a
v
e

s
p
e
n
t

o
n

e
a
c
h

w
o
r
k

i
t
e
m
.
T
h
e

n
u
m
b
e
r

o
f

w
o
r
k

i
t
e
m
s

(
t
a
s
k
s
,

b
u
g
s
)

I

c
l
o
s
e
d
.
K
n
o
w
i
n
g

t
h
e

f
o
l
l
o
w
i
n
g

w
o
u
l
d

h
e
l
p

m
e

a
s
s
e
s
s

m
y

p
e
r
s
o
n
a
l

p
r
o
d
u
c
v
i
t
y
.
5

=

s
t
r
o
n
g
l
y

a
g
r
e
e
4

=

a
g
r
e
e
3

=

n
e
u
t
r
a
l
2

=

d
i
s
a
g
r
e
e
1

=

s
t
r
o
n
g
l
y

d
i
s
a
g
r
e
e
Figure 3.2: Metrics for Assessing Productivity.
3.2 Results 13
Table 3.4: The Information Participants Want to Measure. (#: number of participants, %: percentage of
participants)
# %
activities (how much time was spent where) 67 27.0
achievements (actual work done, progress on tasks) 44 17.7
value (usefulness of completed work, success of the feature, value to the customer) 41 16.5
time per task ratio 39 15.7
number of context switches and distractions 36 14.5
You can measure almost everything, the question is, is it effective to measure it? - Because it costs a lot
of time to measure it and to evaluate the results. (...) But I think those things cant be easily automated,
because every project is so unique and the complexity to test all circumstances will explode. (Web95)
Participants also fear that a measuring tool could be misused to track their performance and result
in adjustment of their salary or goals according to these measurements.
3.2.5 Inuence of Goal Setting on Productivity
One aspect that might have a particularly big impact on a developers productivity is goal setting
and planning, as research found that it can motivate a person to work towards the dened goals,
resulting in a higher chance to meet them [RRMC14, Coo14]. Goal setting and monitoring goals
is widely practiced among our study participants and mostly leads to positive results, which are
presented in the following paragraphs.
Of the 293 (77.3%) participants that regularly set goals for themselves, the majority set goals on
a daily (187, 49.3%) and/or weekly (223, 58.8%) basis. These goals are usually fairly concrete, such
as xing a bug, coding a function or completing the documentation, and mainly differ in their
granularity. While daily goals are often smaller items, such as xing a bug or meeting a person,
weekly goals are often bigger tasks, such as nishing or creating a feature or a new component,
specied in the Scrum planning:
[Daily goals:] implement specic features, like adding a set of GUI elements, get clarity on an aspect of the
problem, like nd out how to implement something. [Weekly goals:] nish part of projects, like implement
a service. (Web132)
Goals give developers a direction for their work, help themto better react on unplanned tasks, and
to reect on their work progress. Only 60 (15.8%) participants stated to dene long-term goals,
such as increasing the code quality or learning a new programming language or framework. 86
(22.7%) mentioned that they do not set any goals at all.
Companies or teams set goals for 50 (13.2%) participants on a daily and for 191 (50.4%) partic-
ipants on a weekly basis, often during daily Scrum or sprint meetings. Companies or teams also
set long-term goals for 117 (30.9%) participants. These long-term goals are often concrete, but
their implementation is relatively vague and developers have some freedom in how to approach
them: release component x, learn something new, increase customer feedback and satisfaction, or
improve overall quality. 105 (27.7%) participants mentioned that their company does not set any
goals for them at all.
Table 3.5: How the Participants Monitor their Goals. (#: number of participants, %: percentage of partici-
pants)
# %
planning (e.g. calendar, task list, work done versus work left) 134 53.2
issue or work item tracker (tools: e.g. Jira, Redmine, TFS, Atlassian, Bugzilla) 68 27.0
code related goal monitoring (quality, successful test runs or builds, cont. integration) 30 11.9
meeting (Scrum/standup meeting, meeting with manager) 19 7.5
mind work (just thinking/reecting about the goals) 12 4.8
Participants who set goals for themselves were then asked about their monitoring practice.
The top ve mentioned goal monitoring practices are presented in Table 3.5. 231 (91.7%) monitor
their goals to see if they will achieve or already achieved them. Most participants (134, 53.2%) plan
their goals using a calendar or a simple task list, either in a digital formor on paper, and frequently
check if they completed a task, check the status of a task, or check how much work is left to do.
68 (27.0%) of all the participants who are setting goals monitor them using an issue or work item
tracker, such as Jira, TFS, or Bugzilla. Similar to the task list, participants mentioned comparing
their planned open work items or issues with the completed ones. 30 (11.9%) participants use
tools to get code specic information to determine the progress on their goals, such as monitoring
their codes quality or running unit or integration tests on their code.
Given the previously mentioned positive inuence of goal setting and planning on develop-
ers, we also investigated the possible effects of the participants goal monitoring practice and if
they change their behavior based on what they learn from monitoring. Most participants (189,
77.1%) believe that monitoring their goals can have an impact on their productivity, while 22
(13.9%) believe that it has no effect. The answers from the remaining 22 (9.0%) were not clear.
88 (35.9%) participants believe that goal-setting does not necessarily help them to increase their
productivity directly. They stated that goal-setting provides them with an overview of their tasks,
improves clarity on what they need to do, lets them prioritize their work, and better react in case
of unplanned tasks, which then helps them to increase their productivity. Dening and setting
goals helps them to work more focused, get less easily distracted by other tasks, and to better
know how to resume a task after a context switch. Thinking back and reecting about their goals
helps 64 (26.1%) participants to determine if they are still on track and to nd productive and
unproductive days:
Monitoring helps to dene realistic goals. Consequently, the goals will be met more likely which increases
satisfaction. Being more satised about the own work makes me more productive. (Web27)
49 (20%) participants believe that monitoring their goals helps them to focus better and work
more efcientOther positive impacts that goal monitoring might have on developers included in-
creased satisfaction or mood. Contrary, goal monitoring might also have negative impacts, such
as the additional workload that comes with goal setting and monitoring, mentioned by 11 (4.49%)
participants), or increased pressure, mentioned by 4 (1.6%) participants.
3.3 Threats to Validity 15
3.3 Threats to Validity
Since the survey participants might not be representative of the general population of software
developers, the generalizability of our survey results might be limited. To mitigate this risk, we
advertised our survey through various channels to a large audience. Having gathered data from
software developers from various countries, and with different levels of open-source and closed
source experience, we believe that our sample is fairly representative of software developers and
that it provides an interesting perspective. Participants could freely decide whether to participate
in the study or not (self-selection). They were informed about the surveys topics, an estimated
duration for the participation and offered an incentive (rafe) for their participation. This could
have biased the selection of participants as only participants who could spare enough time or
were interested in the incentive might have participated. We tried to mitigate this risk by adver-
tising through various channels and offering a very generic incentive.
Chapter 4
Study 2: Observations
The survey results raise many questions: For instance, is there a common meaning between devel-
opers for what constitutes a context switch? How, when and what kind of email must developers
process? When are meetings productive and unproductive to a developer? To investigate some
of the survey results in more depth, we conducted an observational study of software developers
at work. As part of this study, we interviewed developers about their work and work practices.
To structure this chapter, we extracted four themes from the results:
1. the role of tasks in how developers work and how developers view productivity,
2. the role of goals and planning in their perception of productivity,
3. different views on the effect of various kinds of activities on productivity, and
4. the role of uninterrupted work to be in the ow.
4.1 Participants and Method
The observational study involved 11 professional software developers who were recruited from
three international software development companies of varying size (Table 4.1). We used personal
contacts and a recruiting email to solicit participation. Of the 11 participants, two were female,
nine were male and all resided either in the US or Canada. Participants had an average of 5.4
years (3.4, ranging from 0.5 to 8 years) of professional software development experience and an
average of 13.3 years (8.3, ranging from 1.5 to 29 years) of total development experience. The
primary work area of all participants was development and the roles varied between individual
contributor and lead.
The study had two parts. In the rst part, we observed each participant for a total of four
hours on a single workday: two hours before and two hours after lunch. In four cases, we had
to adapt the two sessions to accommodate for the participants availability, still ensuring to have
at least one hour in the morning or afternoon and all four hours on the same day. Before the
rst session, the observer, the author of this thesis, introduced himself to the participant as well
18 Chapter 4. Study 2: Observations
Table 4.1: Observation Study Participants. (Dev: Development, PM: Project Management, IC: Individual
Contributor)
ID
Primary
Role
Development Experience (years)
Work Area Professional Overall
Company R
R1 Dev IC 8.0 14.0
R2 Dev Lead 7.5 8.5
R3 Dev Lead 5.0 11.0
R4 Dev IC 8.0 13.0
Company S
S1 Dev IC/Lead 7.5 14.5
S2 PM/Dev IC/Lead 4.0 22.0
S3 Dev IC 0.5 1.5
S4 Dev IC 12.0 29.0
Company T
T1 Dev IC 2.0 22.0
T2 Dev IC 2.0 5.0
T3 Dev IC 3.0 6.0
as to any colleagues working nearby, asking all to ignore him as much as possible. Before ask-
ing the participant to continue his workday, the researcher provided a short introduction to the
study, placed himself behind the participant to prevent distractions, and ensured being able to
read the contents on the participants screen. The observer noted in an observation log each time
the participant switched a program on his computer, was interrupted by others or interrupted
him or herself, or switched a task while being in the same program. All interactions with others
were also documented, including details about the topic, duration, place, and persons involved.
To ease the transcribing of these events during the observation, we used a small helper applica-
tion developed by the author of this thesis, which automatically lls in the systems time stamp,
provides predened text elds for the event and helps with the analysis of the logged data. The
researcher was very careful to capture as much detail as possible. Whenever something was not
clear, the researcher noted it and asked the participant at the end of the observation session or
in the follow-up interview for clarication. Each entry in the observation log consists of a time
stamp, a reason for the switch, the program that the participant switched to and the task that
the participant was working on. Table 4.2 shows an example of three observation log entries.
Due to condentiality reasons, we are not able to share the original observation logs. An excerpt
of the observation log with more sample data can be found in the Appendix. The preparation
and process of the observation was inspired by Mintzbergs protocol of a structured observation
session [Min80].
Table 4.2: Sample Observation Log Entries.
Created Task Du-
ration
Task Description Task
Number
Application Activity Category
09:29:54 00:00:06 builds project 1 ConsoleApp1 Dev: TestingApplication
09:30:00 00:00:21 modies code 1 EditorApp7 Dev: Code
09:30:21 00:00:12 looks at the task (issue) 1 PlanningApp1 Planning
4.1 Participants and Method 19
Table 4.3: Activity Categories for the Observations.
Category
% of time over
all Observations
Development
Code Reading/editing/navigating code (version control) 32.3%
Debug Debugging 3.9%
VC Reading/accepting/submitting changes 2.4%
TestApp Testing application outside IDE 11.7%
Review Performing code reviews 2.3%
DevOther Other related to development 4.1%
Email Reading/writing emails 4.9%
Planning Editing work items/tasks/todos; creating/changing calendar entries 7.9%
ReadWriteDoc Reading/editing documents and other artifacts, e.g. pictures 2.7%
MeetPlanned Scheduled meeting/call 4.9%
MeetInformal Ad-hoc, informal communication; e.g. unscheduled phone call / IM call, or
colleague asking a question
13.1%
BrowsingRel Internet browsing related to code/work/task 4.0%
BrowsingUnrel Internet browsing work unrelated 0.4%
Other Anything else, such as break or changing music 5.4%
We dened a task as a piece of work with a specic goal or intention, such as xing a bug
or reviewing code changes for a specic work item. We inferred tasks from the active programs
on the screen and the information considered in those programs, such as a work item consulted
before beginning to code. Ten minutes into the rst session, the observer briey interrupted the
participant to validate the tasks the participant was working on.
From the observation sessions, we collected transcripts of a total of 44 hours of work with a
total of 2650 observation events over all 11 developers. During the data analysis, we categorized
each program and participants actions into one of the activity categories listed in Table 4.3, which
we inferred from the survey results and the observations using an open coding technique. The
results are similar to the ones reported in [GM04, Spr84]. The logged time stamps were then used
to calculate the duration spent on interruptions, activities and tasks, amongst others.
All observations were conducted by the same observer. For the rst session of the rst par-
ticipant, we cross-checked the observations by having a second observer. Almost all events were
noted by both observers. Of the total of 202 entries for the rst session, less than 10 log entries
(4.9%) were not contained in both observers logs, while all others matched, suggesting a high
accuracy of the primary observers logs.
In the second part of the study, following the observations, we interviewed each participant
using a semi-structured approach by using a set of prepared questions as general guidance. As
part of this interview, the observer briey discussed the tasks a participant worked on during the
two observation sessions to verify the accuracy of the observation notes. The bulk of the interview
focused on gaining further insights into the observations and to investigate themes arising from
the survey results. In particular, the questions focused on participants perception and reection
of productivity, context switches, work items, code check-ins, meetings and emails and whether
and how information on these might help to assess a developers productivity. Interviews took
between 34 and 51 minutes per participant, with a mean of 43 minutes (5 minutes), and were
conducted in person. The interview guidance notes can be found in the Appendix.
4.2 Results
To present the observational study results, we use the four themes extracted from the survey
results; the role of tasks, goals, activities and uninterrupted work on a developers perception of
productivity. Figure 4.1 illustrates the work of each participant over the two observation sessions.
Each participant and session is represented by a row. Each row is divided into segments, with
each color-coded (grayscales) segment representing a particular task. The gure also shows the
activities undertaken by each participant, discussed in section 4.2.2. The occurrence of the start of
an activity is indicated with a colored shape. The lines emanating from the activity indicate the
duration of an activity. For two participants, we split the 4 hours of observation into one three
hour session and one one hour session. Our analysis of the data in this section considers all of the
data collected over the four hours for each participant. A discussion and more details of the data
represented in the gure are discussed in the following sections.
4.2.1 Tasks
During the observation sessions, participants worked on between 2 and 10 tasks (mean of 4.8,
2.3) each, such as implementing a feature, xing a bug, reviewing code, helping co-workers with
a problem, or reading and writing emails. Each participant switched frequently between tasks
with a mean task switch rate of 13.3 (8.5) times per hour. The average time spent on each task
was 6.2 (3.3) minutes. The number of tasks worked on in the time observed (2 to 10) is similar in
magnitude to the number of working spheres (10), a concept similar to our use of tasks, observed
by Gonzales and Marks in a study that included a small number of software developers [GM04].
The rate of task switching is similar to that reported in both [GM04] and [KAP
+
07].
From the observations and the follow-up interviews, we identied several reasons for why
task switching occurred, including starting a new task after completing the current one, help-
ing a co-worker to make progress (T3), unblocking themselves (S3, S4), similar to [KAP
+
07]. In
several instances, participants switched tasks without any observable reason, which might have
happened due to boredom or even just wanting to switch away from the current task, described
as task avoidance by Ko et al. [KAP
+
07]. Participants also mentioned that task switches occurred
when they were waiting, such as waiting for a build to complete. In these cases, the participants
mentioned that switching to email, code reviews, or other small tasks can help increase their
productivity.
The results of this study also raise questions about the relationships between tasks and track-
able work items. From the survey results, the highest rated measure for assessing productivity
(Figure 3.2) was the number of work items closed. From our observations, we found that the
participants worked on many more tasks than trackable work items. For example, they have
company-wide meetings, help others with their tasks, answer emails, or write reports, which is
often not represented in the work items list. When the participants were asked during the inter-
view how many work items they worked on during that day, answers ranged from one to 13 and
all participants stated that the size of the work items varies.
There could be days where youve been working on one massive bug or issue or identied other sub-issues
into it that need to be resolved, but there could be other days where you just got 20 bugs, but they are all
little things. (R4)
4.2 Results 21
Actvities and Task Switches
Time [minutes]
S
u
b
j
e
c
t
/
S
e
s
s
i
o
n
0 30 60 90 120 150 180
T3/2
T3/1
T2/2
T2/1
T1/2
T1/1
S4/3
S4/2
S4/1
S3/2
S3/1
S2/2
S2/1
S1/2
S1/1
R4/2
R4/1
R3/2
R3/1
R2/2
R2/1
R1/2
R1/1
G
G
G
G
G
GG
G
G
G
G
G
G
G
G
G
GG
G
G
G
G
G
G
G
G G
G
G
G
G
G
G
G
G
G
G
G
G GG
G
G
G
59 activity switches
9 task switches, 2 distinct tasks
G
G
G
G
G
G
G
G
G
G G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
GG
G
G
G
G
G G
G
G
GGG
GG
G
G
GG
G
G
G
G
G
G
GG
G
GG
G
G
GG
GG
G
GG
G
GG
G
G
G
G
G
G
G
GG
G
G
G
G
G G
G
G
GG
G
G
G
G G G
G
G
G
G
G
G
G
G
G GGGG
G
G
G
G
G
G
G
G
G
G G
G
G GG
G
G
G
G
G
G
G
G
G
G
GGG
G
G
G
GG
G
G
G
G
G
GG
GG
G
G
G
GG
G
G
G
G
G
GG
G
G
G
G
G
G
G
G
G
GGG
G
GG
G
G
G
G
G
G
G
GG
G
G
GG
G
G
G
GG
G
G
G
G
G
G
GG
G
G
G
G
G
G
G
G
GGG
G
G
GG
GG
G
G
G
G
G
G
G
GG G
GG
G G
G
GG
G
G
G
G
G
G
G
G G
G
GG
G
G
G
G
G
GGG
GG
G
G
G
G
G
G
G
G
G
G
G
G
G
G
GG
G
G
G
G
G GG
G
G
G
G
G
GG
G
G
G
G
G
G G
G
G
G
G
G
G
G
G
G
GG
G
G
GG
G
G
G
G
GG
G
GG
G 129 activity switches
G
G
GG
GG
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
GG
G
GGG
G
GG
G
G
G
G
G
G
G
GG
G G
G
G G
G
G
G
G
G
G
G
G
G
G
GG
G
GG
GG
G
G
G
G
GG GG
GG
G
G
G
GG
G
G
G G
G
G
GG
G
G
G
G
GG
G
G
G
GG
GG
G
G
G
G
G
GG
G
G
G
G
G
GG
G
G
GG
G
G
G
GG
G
GG
G
GG
G
GG
G
G
G
G
G
G
G
G G
G
G
G
G
G
G
G
G
GG
G
G
G
GG
G
G
G G
G
G
G
G G
G
G
G
GG
G
G
G
GG
GG GG GG
G
G
G
G
GG
G
G
G
G
G
G
GG
G
G
G
G
G
G
G
G
G
G
G
G
GG
G
G
GGG
G
G
G
GGG
G
G G
G
G
G
G
G
G
G
G
GG G
GG
G
G
G
G
G
G
G
G
G
G
G G
G
G
GG
G
G
G
G
G
GG
G
G
G
G
G
G
G G
G
G
G
G
G
GG
G
G
G
G
G
G
G
G
G G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
GG
G
G
G
G
GG
GG
GG
G
G
G
G
G
G
G
G
G
GG
G
G
G
G
GG
GG
G
G
G
G
G
G
G
GG
G
G
G
G
G
G
G
G
G
GG
G
G
G
G
G
G
G
G
G
GG G
G
G
G
G
G
G
G
G
G
GG
G
GG
G G
G
G
G
G
G
G
G
G G
GG
G
G
G
GG
G
G
G
GG
G
G
G
G
G
G
G
G
G
G
G G
G
G
G
G
G
G
G
G
G
G
G
G
G
G G
GG
G
G
G
GG
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G GG
GG
G
G
G
G
G
G
GG
GG GG
G G
G
G
G
GG
G
GG
GG
G
G
G
GG
G
G
G
G
G
G
G
G
G
GG
G
G
G
G
G
G
G
G
G
G
G
G
G
GG
G
G
G
G
G
G G
G
G
G
G
G
G
G
G
G
G G
G
G
GG G
G
G
GG
G
G
G
G
GG
GG
G
G
G
G
G
GGGGG
G
G
G
G
G
G
G
G
G
G
GG
G
G
G
G
G
G
G
G
G
G
G
G
GGG
G G
G
G
G
G
G
G G
G
G
G
G
GG
G
G
G
GG
G
G
G
G
G
G
G
G
GG
G
G
G G
G
GGGG
G
G
G
GG
G
G
G
G
G
GG
GGG
G
G
G
G
G
GG
G
GG
G
G
G
G
G
G
G G
G
G
G
GG
G
G
G G
G
G G
G
G
G
G
G
G
G G
G
G
G
G
G
G
G
G
G
G
G
G
G
GG
G
G
G
G
G
GGG
G
GG
G
G
G
G
G
G
G
GG
G
G
G
G
GG
G
G
G
G
G
G G
G
G
G
G
G
G
G
G
5 activity switches
G
G
G
G
G
G
G
G
GG
G
G
G
G
G G
G
G
G
G
G G
G GG G G
G
25 task switches
4 distinct tasks
G
G
G
G
G
G G GG
G
G
G
G
G
G
G
G
G
G
G
G
GG
G
GG
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
61 task switches
6 distinct tasks
G
GG
G
G
G
GG
G G
G
G
G
G
G
G
G
G
G
G
G
G
G
GG
G
G
G
G
G
G
G
G
G
GG
G
G
G
G
G G
G
G
G
G
G
G
G
G
GGG G
GG
GG
GG
G
G
G
G
GG
G
G
G
G
G
GG
G
G
G
G G
G
G
G
G
G
G
GG
G
G
G
G
G
G
G
Dev:VC
Dev:Debug
Dev:Code
Dev:Review
Dev:TestApp
Dev:Other
BrowsingRel
BrowsingUnrel
MeetInformal
MeetPlanned
Email
Planning
ReadWriteDoc
Other
Figure 4.1: Developers Activity and Task Switches in the Two Observation Sessions.
The varying size, granularity, and difculty of work items likely introduces problems for using
the measurement of the number of work items closed as a sole means of productivity assessment,
at least for shorter time periods, such as a day. Participants did mention the use of the number
of closed work items as one that is used to reect on a teams productivity, such as in meetings
associated with the end of an agile sprint.
4.2.2 Activities
During the sessions, participants switched activities 47.0 (19.8) times per hour, spending on
average 1.6 (0.8) minutes on an activity before switching. Table 4.3 shows the percentage of time
across the observation periods that developers spent in each activity. Unsurprisingly, given our
selection of participants, the largest amount of time was spent on coding (32.3%), with testing the
application also taking an average of 11.7% of the observed time for each participant.
Based on a n-gram analysis of the activities recorded, we found that developers most fre-
quently switched back and forth between coding and testing. Following coding, the next activity
was testing in 28.5% of the cases; a similar result holds for switches from testing to coding. Cod-
ing was also often superseded by an informal meeting (14.9%) either because someone asked a
question or the participant asked someone else a question. After an informal meeting, develop-
ers either went to coding (26.1%), testing (14.8%) or right into planning (18.3%). Finally, emails
were mostly checked while coding (18.8%) or testing (19.4%) and developers generally returned
to testing (20.7%), coding (17.2%) or planning (19.5%) after the email check.
Informal Meetings. Interestingly, the second highest activity in terms of amount of time spent
(Table 4.3) was informal, ad-hoc meetings (13.1%), ranging from instant messages to a colleague
interrupting and asking questions. During the interviews, participants described having between
one and ten informal meetings per day, taking anywhere from one minute to two hours. The
participants in this study agreed that unplanned, informal meetings are usually productive as
they are generally short and efcient, and often succeed in helping to unblock the initiator of the
conversation. Still, these unplanned meetings can be quite stressful, as both developers want to go
back to their own tasks as fast as possible. Usually, participants reaction to such an interruption
was quite positive, as they consider these informal meetings as an investment to help the co-
worker and to move the team forward.
Planned Meetings. Unlike the survey respondents, participants in the observational study found
all meetings generally productive, whether informal or formal. Participants in this study de-
scribed having had 5 to 10 planned meetings in the past ve workdays (usually one to three
meetings per day), taking anywhere from 15 to 60 minutes each and uniformly stated that having
more than two meetings a day decreases their productivity. Participants did describe formal meet-
ings as more productive when only a few people are involved, there is a concrete outcome and the
participant feels useful in the meeting. Participants stated that formal meetings are unproductive,
if not all participants are needed or if the goal of the meetings is just to deliver information that
could easily be distributed via email (e.g. sales meeting).
4.2 Results 23
Emails. Most survey respondents described email activities as unproductive (62, 18.8%) com-
pared to productive (10, 3.0%). Given that participants in the observational study spent on aver-
age just under 5% of their time handling emails (see Table 4.3), the inuence of emails on their
productivity might be small compared to other activities. We observed participants regularly
checking their emails during the observation, 4.3 (2.9) times per hour on average:
If someone is trying to contact me and they have a problem, I dont want them to wait too long. There is
this mail clock ticking. At some point you have to go check it. (T1)
Participants stated that they do this because they either want to keep their inbox clean or do not
want their co-workers to wait too long for answers to their questions. Without being specically
asked, 5 of 11 (45.5%) participants mentioned having issues with emails as they sometimes put
a lot of pressure on them, similar to [IH07]. In particular, lengthy email conversations that go
back and forth with multiple respondents, and constant questions via email, followed by the urge
for an immediate response. All three companies where we run our study handle emails differ-
ently: In company T, for example emails are the main mean of communication, whereas company
S usually only uses emails to communicate with people outside the inner team. In many cases,
participants reported that emails are not the best mean of communication for that particular case,
as they often prefer a face to face discussion or a quick call. To better handle the masses of emails
they receive, participants reported between 5 and 100, many participants set up different lters
and tags to clean their inbox and to nd important emails faster.
4.2.3 Work Flow
We were surprised by the number of task and activity switches performed by the developers we
observed. In particular, as the participants of both studies had expressed concerns that context
switches lead to a loss of productivity, while 8 of the 11 (72.7%) participants observed felt that their
sessions were productive, even if the made so many switches in the four hours of the observation.
To understand the relationships between task switches, activity switches and context switches,
we asked the participants in the observational study to dene a context switch. The participants
predominantly described a context switch as a change in thinking, as in:
When I have to stop thinking about one thing and start thinking about something else. (T1)
Participants did go on to discuss the range of context switches from small ones, such as getting
distracted due to background noise or switching between programs when working on the same
task (R2, R3), to switching between a main task and small other tasks such as code reviews or
writing an email (R4) to total switches, switching between two cognitively different tasks (R1).
Although all participants agreed that context switches generally reduced productivity, the
cost or harm is dependent upon the reason for the switch, the duration of the switch, how much
attention the disruption requires, the focus on the current task, and the difculty of the new task.
The price of the context switch is small if the new task is simple. Contrary, the price is high if the
new task is not trivial. The longer the switch the more expensive:
[To] stop and work on a different task is a more costly context switch than writing a quick email. (S1)
Similarly, the more a developer is focused on a task, the more expensive the switch,
[It] depends on where I was, if it was a critical section, it is really hard to get back to focus on that task,
even if it only was for like 30 seconds. (R3)
And also, switching away from a creative task for which more focus is required is more expensive
than switching from a routine task (S2). A self-inicted context switch, such as going for a coffee
break or writing a quick, task-unrelated email, is less expensive than externally imposed switches,
such as interruptions by co-workers or an unplanned task (S2, T2). Finally, the cost of a context
switch is also dependent on the degree and how stressful it is (S2, R2, R4).
The distinctions in the kinds of context switches help explain why the participants felt their
work sessions were productive despite high numbers of task and activity switches. In particu-
lar, we observed the participants often switching to simple tasks, such as reviewing code for 30
seconds or answering an email, without apparent signicant impact to a primary task, such as
xing a bug. Developers also adapt at using waiting times, such as waiting for builds to com-
plete, to perform low cost switches to tasks on which they could make progress. These short
fast task switches are even faster than those reported by Gonzales and Marks in a study of busi-
ness analysts, software developers and managers; they reported fast task switches as spending
approximately two and a half minutes at a time on email [GM04].
4.2.4 Goal Setting and Planning
Participants spent on average 7.9% of the time observed with planning related activities (see Ta-
ble 4.3). Most participants use standard features of their work item trackers, such as the issue
navigator in Jira, to have an overview of their work, while 6 (54.5%) use task lists on paper or
note taking programs as a supplement. Prioritizing their work items and planning reserve times
helps participants to better react in case of an unplanned task, to easier resume interrupted tasks,
and to better use waiting times, similarly to what we learnt from the survey (S2, S3, S4, T1, R4). It
also helps participants to better focus on the current task and to get distracted less easily:
It gets me a little bit more focused to know what I should be doing. Thats why I have the todo list. (R3)
Similarly to our survey ndings, most participants (9 of 11, 81.8%) regularly reect on their pro-
ductivity to determine their progress on the tasks, while no participant uses any kind of produc-
tivity analysis tool:
I just reect back on what I accomplished in the amount of time, but again all mind work, no analysis [tool]
or anything. (S10)
Participants use this information to nd out why some tasks took longer than expected (S3, R1),
plan the next workday (R3), and decide whether and how to change habits and improve oneself
(S4). This sometimes leads to interesting ndings, such as the one by R1, who usually feels less
productive on Mondays and Fridays and adapted her behavior to work on the most difcult tasks
on her more productive days:
I usually feel less productive Mondays and Fridays. [It] takes me a while to ramp up mentally for the week
and ramp down (. . . ) at the end of the week. (R1)
However, participants also mentioned problems and difculties they face when they plan their
workdays, which prevents them to perform their workday according to their plan. These include
unexpected urgent tasks, mentioned by all participants, planning errors due to different work
item sizes (S2, T3, R1), and having received no training in planning (R4). Nevertheless, some
participants (S3, T1, T3, R4) mentioned that they still feel productive and make progress, just not
on the tasks they intended to work on:
Often times, urgent bugs are difcult, often times it will take several days of investigation and lots of work.
So they might slow down, whatever else I was doing. But in some sense, if I am working towards resolving
a certain bug thats still being productive. I wouldnt call that burnt [i.e. wasted] time. (T3)
4.3 Threats to Validity 25
4.3 Threats to Validity
The small number of participants in our observation and interview study, the use of personal con-
tacts for inviting participants and the short sessions capturing a total of 44 hours of work might
limit the generalizability of the results of this study. We tried to address this threat by select-
ing participants from three different international software companies. Furthermore, the strength
of our mixed method approach allowed us to triangulate ndings obtained through the survey
study with the results from the observations and follow up interviews. Additionally, participants
were observed in their normal real-world work and not during an experimental exercise.
Another limitation might be the study setting of observing participants for 4 hours in one
day. Participants could have had a particularly productive or unproductive day, or other factors
could have inuenced them. Furthermore, by sitting behind the participant and observing him or
her, the observer might have been a source of distraction, inuenced the work style or prevented
interruptions by co-workers. We tried to mitigate this risk by splitting up the session into two,
two-hour sessions, sitting as far away from the participant as possible and telling co-workers
beforehand about the study and that they should continue and interrupt as usual.
The collection and categorization of data poses another threat to validity, since it is not straight-
forward to identify task switches or not miss any switches. To mitigate these risks, all observa-
tions were done by the same researcher and task switches were conrmed with participants. A
cross-validation was also done for the rst session, showing signicant agreement between the
two observers.
Finally, the interviews and qualitative analysis was performed by one author using grounded
theory techniques, such as open, axial and selective coding. To avoid observer bias, several parts
of the survey, interview and observation were analyzed and open coded by at least one more
author.
Chapter 5
Discussion And Future Work
Our ndings from the two studies help to answer our research question, by contributing new
knowledge about how developers perceive their own productivity and how it relates to their
software development work. Despite the general interest of our participants in assessing and im-
proving their productivity, there is little tool support to help them and only few best practices
recorded. Opportunities exist to better support developers in managing and improving their
work to achieve higher productivity levels, such as best practices in goal setting, approaches in
reducing context switches, and a new approach creating a retrospective analysis. In this chap-
ter, we share best practices from our participants and related work to improve the developers
productivity, analyzing existing tools and suggesting some design implications for new tools.
5.1 Setting Goals
The setting of goals is one technique that can be used to motivate and enforce a behavior change.
For example, goal-setting has been shown to be successful in motivating people to be more active,
in particular in combination with self-monitoring (e.g. [BSSS
+
07, CKML09, FHMZ14]). When it
comes to software development, many of our participants stated to set goals for themselves on
a daily or weekly basis. Although the developers did not necessarily believe that goal-setting
directly helped them to increase their productivity, they stated that the goals provide an overview
of their tasks, allow them to prioritize work, and to better react in cases of unplanned tasks, which
were mentioned to be a major detriment to being and feeling productive. Some participants
mentioned being able to work more focused, getting less easily distracted, and being able to
better resume tasks after a context switch, when they dene goals.
Impact of Goal Monitoring With respect to monitoring their goals, 189 (77.1%) survey par-
ticipants believe that it can have an impact on their productivity as well as on their mood and
motivation. Thinking back and reecting about their goals gives them a feedback of their work to
know if they are still on track and to nd productive and unproductive days. Several interview
participants (S3, T3, R1, R3) stated to have changed their work schedule and work place based on
their ndings from monitoring their goals, e.g., to work on important tasks during times when
28 Chapter 5. Discussion And Future Work
they can focus best:
Monitoring my work has a great benet on my productivity. If you cant measure something, you cant
understand it. If you cant understand it, you cant control it. If you cant control it, you cant improve it.
(Web44)
However, monitoring goals either requires manual work by the developer or measurements that
can be tracked automatically, and describe the progress towards fullling a goal. This is why
a few survey participants (11, 4.9%) fear the negative effect goal monitoring can have and stated
that the additional time needed for monitoring could be better used for actual work. From talking
to developers in the interviews, it seems however that the overhead of setting goals is negligible
and maybe well worth it to better structure the next workday and thus make them more focused.
Setting Goals as a Best Practice In both studies, participants shared various techniques and
tools to set goals. Most participants mentioned work items and other tasks, and only very few
set goals for other aspects of their work, such as software quality or testing results. It is com-
mon practice, that participants maintain their task list in a work item tracker (often Jira, Bugzilla,
or TFS) and plan their work in the calendar (often Microsoft Outlook or Google Calendar) or a
note taking tool (often Microsoft OneNote or Evernote). Most of the mentioned tools lack an au-
tomated aggregation of tasks from multiple different sources, such as work item trackers, open
emails, the personal task list, and an integration into the developers IDE, leading to inefcient
switches between different task lists and the development environment. Some participants men-
tioned being sometimes overwhelmed and having difculties to keep an overview of the growing
task list, especially when they have to deal with unplanned work. This is why they are generally
open to try new tools and approaches, such as Wunderlist (Web10, Web27, Web181) and the Get-
ting Things Done
1
method by David Allen [All03]. This variety of tools available to plan and
monitor participants goals and the high satisfaction amongst participants with their current goal
setting technique is a best practice that could be shared amongst developers.
Possible improvements to current practices of goal setting may be to better aid a developer to
plan his work, and a better aggregation of all the tasks from various sources, such as work items,
emails, other task lists, and notes, into one single list. Similar to popular personal sport trackers
which are successful in motivating people to being more active (e.g., [FHMZ14]), we think that
a suggestive personal tool could help developers increase their intrinsic motivation and better
plan their work. For example, it could help the developer to set goals which are more realistic
to achieve, it could suggest to plan difcult or important tasks for the developers most efcient
times, it could remind him of the progress he (or his team) already did on a task, or it could sug-
gest a co-worker to ask when he is stuck on a problem. It could also help the developer to better
plan his work by suggesting tasks that are similar and t well to be worked on contiguously and
might make it easier for the developer to prepare for a bug-xing day, for example. To have
the greatest persuasive power as discussed by Fogg [Fog03], these suggestions must be shown in
the right situation and the most opportune moment. For example, when a developer feels he is
unproductive, he could click a virtual Help! button of a tool that analyzed his behavior in the
background and get suggestions on the most opportune action to get out of the desperate situa-
tion. More research needs to be conducted to better identify opportune situations for suggestions.
1
The idea of the Getting Things Done approach is to move planned tasks and projects out of the mind by ling them
externally, and breaking them down into actionable work items.
5.2 Retrospective Analysis 29
5.2 Retrospective Analysis
It was surprising to learn that even though they performed many context switches in the four
hours of the observation, 8 of the 11 (72.7%) participants still felt productive. The reason for this
might be that participants have a different idea of what productivity is, than how they actually
assess it, as described in chapter 3.2.3. Even though participants are generally interested in maxi-
mizing their own productivity and have ideas to do so, as described throughout this thesis, they
rarely take any actions to improve oneself, which leads to the question why they are not doing
more? We believe that the answer is manifold: Developers might feel being unproductive, but
might not think about and reect about reasons for their inefciencies, as this unproductive feel-
ing might be not that disturbing to really change something. Another sign could be a lack of tools
and techniques to support developers to reect about their productivity and point out unpro-
ductive times. Lower barriers to change and a better assessment of the impact a context switch
has on a developers productivity could help the developer devise approaches to optimize the
productivity gain.
An Approach of a Retrospective Analysis Self-monitoring can provide valuable insights into
ones own behavior and reecting about self-monitored information can be used to change ones
behavior (e.g., [Fog03, Mun12]). In particular, activity tracking devices have been shown to be
successful in promoting individuals to adopt a more active lifestyle (e.g., [CMT
+
08, FHMZ14]).
There has been growing interest in this area with devices such as the Fitbit, which tracks such
information as the number of steps per day and the number of stairs walked per day, and the
Nike+ Fuelband, which aggregates such individual measurements into a proprietary notion of
fuel. Given that participants in our two studies did assert interest in measuring their productivity,
what might similar individual or aggregate measurements be that are useful for tracking and
reporting to software developers?
Although developers in our survey rated on many individual measurements (Figure 3.2), fur-
ther investigation of the top ranked item in our observational study indicated the difculty of
using one simple measurement, in this case, number of work items closed. Taken together, the re-
sults of the two studies suggest that there might not be a single and/or simple measurement for a
developers productivity. For example, while summarizing the time developers spent on certain
activities during the day might provide some insight, as for example done by Codealike, to be
more meaningful it has to be combined with measurements that also provide a certain, possibly
personal, assessment of the productivity of the time spent, such as the progress made towards
certain tasks, the value of the task for the customers, or how focused the developer was during
the time. Based on a combination of such measurements, some of which might be qualitative
rankings by a developer, one might be able to abstract these to an overall productivity level for
a day, not unlike the Nike fuel idea. Seeing uctuations in an abstracted measurement may pro-
vide sufcient support for a developer to retrospect on how work was performed, particularly if
detailed information could be provided, such as the visualization of task and program switches
in Figure 4.1.
We believe the benet of enabling and driving retrospection may be the key rather than trying
to dene measurements that can be compared across individuals or across organizations. By
driving productivity for the individual in a personalized way, we can also help assuage various
privacy concerns mentioned by the participants in our studies with who might be able to see
productivity information and to whom it might be compared, such as co-workers. This is almost
contrary to what Rooksby et al. found in [RRMC14], where they describe that personal tracking is
often social and collaborative rather than personal. Maybe, users are more likely to exchange their
sport activity data with others than information about the productivity of their work, which could
have an inuence on the salary of their job and even demotivate a developer if his productivity is
constantly lower than the teams average.
The following paragraphs present our idea of an aggregate approach to visualize and report
productivity that is driven by the individual and could be used as a positive reinforcement that
hopefully drives up productivity. The ideas for this approach stem from the open coding analysis
of our studies, further analysis of related work and existing approaches, and our own experience
and ideas. Subsequently, we conducted an afnity study with two doctoral students from our
research group to discuss our results from different angles, validate our early tool ideas, and
identify new design implications to support developers in improving their productivity.
Five Stages of Retrospection In their work to offer creators of a personal informatics system
a comprehensive list of problems that users experience, Li et al. [LDF10] designed a ve stages
model of the personal informatics system: 1) at the preparation stage, users need to determine the
information they want to record and how to record it; 2) at the collection stage users do the data
gathering or tracking; 3) at the integration stage the data should be prepared, combined and trans-
formed; 4) at the reection stage users can think about, explore and interact with the information
(and enhance it); and nally 5) at the action stage users can choose what they are going to do with
their newfound understanding of themselves. As numerous papers based on this stage-based
model to describe their personal informatics systems, we use the same model to structure the
presentation of our approach, summarized in gure 5.1.
Figure 5.1: Overview of a Possible Retrospective Analysis of a Developers Workday.
1. Preparation Stage In the preparation stage, the developer should specify the goals he wants
to meet during his workday or workweek, based on a list of measurements that could be tracked
in the background. Table 5.1 contains a selection of such measurements, why they might be in-
teresting to the developer, how they could be represented or visualized, and how they could be
quantied. They were selected based on ndings from our studies, related work, our own expe-
rience, and the previously described afnity study. In Table 5.2, three higher-level measurements
are presented which base on the just presented measurements and possibly some tracked data
from sensors. To be valuable for his retrospection, the user needs to reect on and interpret the
data of these measurements (see the reection stage), i.e. the developers focus on his work, the
progress on his tasks, and the ratio of work related versus work unrelated activities.
Goal setting, as frequently practiced by developers (see Section 5.1), was shown to motivate a
person to work towards the dened goals, resulting in a higher chance to meet them [RRMC14,
Coo14]. To enable the retrospection, the user has to dene at least one goal, a goal that motivates
him to be more productive or avoids him to do productivity decreasing activities. Examples for
goals set by developers are: to focus for at least 6 hours a day, to be interrupted not more than 3
times a day by a co-worker, to attend not more than 2 meetings, or to do work unrelated activities
less than half an hour a day. By letting the developer specify goals for a set of measurements and
tracking these, the tool could determine whether the goals are met or not and could calculate the
progress.
2. Collection Stage This stage starts as soon as the developer specied the measurements to be
tracked and the goals he wants to achieve. Many participants mentioned that the tool should be
non-intrusive and work in the background, where it automatically collects data about the speci-
ed measurements. The data should always be up-to-date and require no additional input. Par-
ticipants did not agree whether the collected data should be modiable or not as some stated
having more trust in the data if it was editable, while others would not use a tool that requires
additional user input.
3. Integration Stage Similar to the previous stage, no action by the developer is required in
the integration stage. When the developer wants to access his retrospection, the collected data is
processed, to compare it with the developers goals, and visualized.
4. Reection Stage Survey participants seemed to value simplicity over accuracy and func-
tionality, as they wished to just have a simple dashboard summarizing the tracked data or even
just a trafc light to see whether they are productive or not. As described by Fritz et al. [FHMZ14],
this notion of simplicity is also successfully implemented by various activity trackers (e.g., Fit-
Bit, Nike+ Fuelband). Bentley et al. go one step further and try to avoid visualizations by ver-
bally conveying statistical data instead of using bar or pie charts [BTS
+
13], as Galesic and Garcia-
Retamero [GGR11] found in a study that 41% of Americans as well as 44% of Germans lack the
ability to understand and apply data from graphs.
A possible retrospective visualization of a developers progress towards his daily or weekly
goals is visualized in Figure 5.2. The developers progress towards his goals is calculated from
the tracked data and visualized among other details. A merged summary of the different goals
are visualized as another progress bar, the productivity fuel. This productivity fuel gives the de-
veloper a quick indication whether he achieved his goals or not. Similar to Bentley et al.s mobile
Table 5.1: Selection of Possible Tracked Measurements for the Retrospection. (TN: total number, AD:
average duration)
Measure Reason Representation Quantication
Code Accounts for 56.7% of
the developers work
(see Table 4.3) and
might help to iden-
tify achievements and
progress of work.
Code related measure-
ments: e.g. loC, TN of
attributes, methods and
classes added or modi-
ed, TN of commits.
Use data from existing
trackers inside the IDE,
build tools, or version
control tools.
Emails Mentioned by partici-
pants to be one of the
major sources for being
unproductive.
TN of (unread) items in
the inbox,
TN of items sent and re-
ceived,
average response time.
Tracker inside the email
application.
Active com-
puter use
Determine when
the developer is not
actively using his com-
puter, e.g. interruption.
On a timeline,
needed for a more accu-
rate quantication of the
developers activities on
his computer.
Computers keyboard
and mouse input.
Notications Sources of distractions
and interruptions, pos-
sibly leading to inef-
ciencies.
On a timeline,
TN of notications.
Track system, email, and
IM notications.
Interruptions Major detriment of a
developers productiv-
ity. Possibly helpful
to nd productivity
losses.
On a timeline,
TN and AD of interrup-
tions.
Possible interruption:
switch to a just arrived
email, IM message, or
call, no keyboard and
mouse input, or mo-
tion or noise sensors
recognize discussions.
Meetings Mentioned by partici-
pants to be one of the
major sources of being
unproductive.
On a timeline,
TN and AD of meetings,
topics of meetings.
Create a hook into the cal-
endar.
Waiting
Times
Possible sources of task
switches, leading to in-
efciencies.
On a timeline,
TN and AD of waiting
times,
reasons for waiting
times.
Recognize waiting times
inside the IDE: e.g. du-
ration of builds and test
runs.
Activities The programs a devel-
oper uses and the activ-
ity switches. The way
he structures his work.
On a timeline,
TN and AD of each ac-
tivity.
Track on the users com-
puter. Complement with
other measurements, e.g.,
interruptions, meetings,
waiting times, active
computer use.
Tasks Justies the developers
workday and progress
on his tasks.
On a timeline,
TN of tasks,
task switches.
Infer from the work items
list, meetings, emails,
opened programs. Pos-
sible task switches occur
during waiting times or
interruptions.
Table 5.2: Possible Higher-Level Measurements for the Retrospection. (TN: total number, AD: average
duration)
Measurement Reason Representation Quantication
Focused Work Developers perceive
to be more produc-
tive when working
focused for longer
periods of time.
On a timeline
TN and AD of
focused work
blocks.
The more focused. . .
. . . the lower the task switch rate.
. . . the fewer interruptions.
. . . the higher portion of work re-
lated work.
. . . the lower the number of activ-
ity switches.
. . . the higher the motivation.
Progress on
Tasks
Wished by study
participants to bet-
ter understand their
workday.
Percentage of
completed tasks
TNof completed
tasks.
Artefacts created, time on an ac-
tivity that can be related to a
task, change of work item status,
progress on sub-tasks.
Private versus
Work Related
Activities
Private activities
are a detriment of
the participants
productivity they
want to avoid.
On a timeline
TN and AD
of private and
work related
activities.
Work unrelated: private smart-
phone use, visit of work un-
related websites, private emails,
chats with private friends. Any-
thing else has a higher probability
to be work related.
application that displays signicant observations of a users activity using natural language, our
tool could make simple statements about the developers productivity, such as You focus less
after lunch.. The information from this example could help the developer to better plan work
that requires high focus for the times of the day he is the most focused.
The tool should avoid telling the user whether he was productive or not, rather than visual-
izing him the tracked data and giving him statistically signicant clues, and let him interpret the
data himself. This approach is also supported by the ndings from our studies where we con-
cluded that there might not be a single right measurement to assess a developers productivity
and that measuring ones productivity is an individual task, different for each developer.
One aspect that may inuence the reection of a developer is the accuracy of the tracked data.
As it turns out from our survey and related work (e.g. [RRMC14]), the abstraction and simplicity
of the data visualization is more important than very accurate data. Reasons for this could be
that the error of the tracked data might be neglectible as the developer is not interested in exact
values but a trend. Not only the selection of the heuristics, but also the user has an inuence
on the accuracy of the tracked data, as some users are likely to try to game metrics to get more
positive results [BVvD12]. It remains unclear if this is also the case for self-monitoring, or only if
the immediate benet is not seen [BVvD12].
Figure 5.2: Design Prototype of a Possible Implementation of the Retrospection Approach.
5. Action Stage Based on the developers feeling about his productivity, his retrospection (see
the reection stage), and possibly some suggestions, he might be able to identify productivity
issues and improve on them. As long as a developer feels productive and the productivity fuel
represents a similar insight, he might not want to change something. But when he is feeling un-
productive, or the tool recognizes a decreasing productivity, it might be the most opportune mo-
ment (as described in [Fog03]) to place concrete suggestions to encourage the developer to change
his behavior, such as using a web blocker if the developer is frequently visiting news websites.
This change might be just short-term, but could also lead to longer term behavior change if the
tool succeeds in pointing the developer to valuable insights to get more productive. Missing the
goals for a day might have a positive effect on a developer to work harder the next day to achieve
his goals, but could negatively inuence a developers motivation if he frequently misses them.
This is why the analyzed data could also be used to adjust the goals a developer sets for the next
tracking period, for example by lowering the bar if he never achieves them.
The described approach could allow a developer to get valuable insights into his workday or
workweek by comparing his own goals with tracked data, which is customizable to meet each
individual developers needs. In the retrospection, the approach would visualize the progress to-
wards achieving ones goals using an abstract measurement, similar to the Nike+ Fuelband. The
tool should also be exible enough for a possible changing process, as an observational study par-
ticipant (S4) mentioned that his thinking about what productivity means shifted over time, sug-
gesting that reection of productivity might not be constant. Finally, not only developers could
benet of this approach, but also teams or managers, by setting and monitoring anonymized team
goals, such as quality, employees happiness, focus, or others. In the future, we plan to develop
and evaluate a prototype of this idea to nd out how well it serves the described purpose, how
well it is accepted by the users, and how and what kind of behavior changes it can induce.
5.3 Reducing Context Switches 35
5.3 Reducing Context Switches
Participants in our study mentioned that being focused and in the ow without context switches
increases their productivity, which is why they think reducing the number of context switches to
have a huge potential to increase their productivity. Identifying a developers context switches,
however, is not an easy task given the fuzzy and various denitions developers have of a con-
text switch. Furthermore, in the light of several developers stating that they would like to work
focused on a task for 2 hours, it is surprising that during our observations context switches were
fairly frequent, occurring at least every 4.5 minutes, and yet developers perceived their produc-
tivity as high. As pointed out by several developers, this indicates that it is heavily dependent
on how much a context switch really deters from the current task and forces him to switch his
mental model of the current task. This increases the difculty of automatically identifying the
productivity loss through a context switch, since the same kind of switch, e.g. an interruption by
a co-worker who comes to ask something, could either be fairly minor when the question is on
the same task, or very substantial when it is on something else.
How can one automatically identify context switches in a developers work given that the
switch is based not only on the program used, not only on the task dened, but on the seman-
tics of the work the developer is performing? For instance, a developer might be switching to
respond to a personal email after writing an email to a colleague about a problem in the code,
thus staying in the same program but still switching context. Participants in our observational
study clearly stated that quick context switches to perform such a task, as reading email while
waiting for a build, did not impact productivity but switches that require a change in thinking
are most costly and do impact productivity. Further studies are needed to determine whether it
is possible to correlate program switches to help enable the determination of the cost of a context
switch, for instance, a switch from a program that enables builds to be launched to email may
be considered a low cost context switch. Investigation is also needed to determine if analysis of
the information in programs used adjacently can help in assessing the cost of a context switch.
Perhaps the combination of the correlation of program usage with the correlation of information
in adjacently used programs can help assess whether it is more likely that the switch is between
semantically different tasks rather than just a program switch and thus more likely to have a high
cost. This information could be helpful in the development of aggregate and individual produc-
tivity measurements and could be helpful to support developers in reecting upon their work
habits.
Participants switch contexts for various reasons, such as completing a task or being stuck on
one, interrupting oneself, or for external reasons, most often induced by distractions and interrup-
tions. In the following, we present participants best practices to minimize these context switches.
Minimizing Self-Interruptions In our observations, context switches caused by self-interruptions
accounted for 50.8% of all context switches and usually ranged from a couple of seconds up to
20 minutes, with a mean of 1.3 (0.7) minutes. Our data conrms previous studies indicating
that people interrupt themselves as often as they are interrupted by others [Spr84, CHW04, GM04,
MGH05]. Further, our data suggests that developers in open plan ofce environments interrupt
themselves at a higher rate, which is similar to [DMG11]. In open plan ofces, participants in-
terrupted themselves on average 12.9 (5.7) times compared to 10.7 (10.7) times for participants
with own ofces during the four hours of the observation. Based on participants answers, we
could nd different situations for developers interrupting themselves, such as having private
conversations, writing a message on the private smartphone, or browsing work unrelated web-
sites, for instance social networks, online chat services, or news websites. The reason for these
self-interruptions is that the developers mind just wanders off (R3), because they lack intrinsic
motivation, e.g., when they do not agree with a task, because they have a very difcult or time
consuming task, or because they have only little time pressure. However, this is very individual
and not an issue for all participants.
Being asked about best practices to avoid switching, participants mentioned a few, such as
browser extensions that block work unrelated websites and the Pomodoro Technique [pom],
which helps them to focus for 25 minutes on just one task and also plan their breaks of 5 minutes
after a focused work block. Participants mentioned another way to minimize self-interruptions,
which is increasing their intrinsic motivation to have a driver to work (S11): Generally, work
should be fun, interesting and demanding, the developer must be proud to work for the product,
and feel that his work adds to the success of the product. Related work described several other
actions which could increase the intrinsic motivation, such as making developers feel valuable
and give them interesting work, which makes them happier [Kon14] and results in better prob-
lem solving [GWA14], nd and remove sources of stress [Kon14], or encourage them to have a
good work-life balance [Kon14]. We believe that goal setting and planning, described in section
5.1, might also help developers to work more focused towards their own goals, which would re-
duce self-interruptions. Further research has to be conducted to investigate approaches to avoid
self-interruptions in a developers everyday work.
Minimizing Distractions and Interruptions The Oxford Dictionary denes a distraction as a
thing that takes your attention away from what you are doing or thinking about [WMT08]. The
inuence of possible distractions, such as background noise in an open plan ofce or notications
from emails and social networks, have been discussed in [CHW04, GM04, IH07]. A software de-
veloper who is less focused or concentrated or is doing boring or rote work is often more suscepti-
ble for distractions [MICJ14]. These distractions and other incidents, such as a planned meeting or
a phone call, may interrupt the developer and detract him from his current task. An interruption
is dened as something that temporarily stops an activity or a situation in the Oxford Dictio-
nary [WMT08] and is usually outside the developers control. In the observations, interruptions
ranged from a couple of seconds to over 40 minutes, with a mean of 2.4 (1.4) minutes.
Context switches caused by distractions and interruptions often require the developer to stop
his current work and start thinking about something else. This constant switching between differ-
ent tasks, generally referred as multi-tasking, is leading to a fragmented attention, reduced con-
centration, more errors, and an increased time to complete tasks [MICJ14, IH07, CHW04, GM04].
This is why interview participants and researchers [Vra14, Kon14] suggest to focus on just one
task at a time (single-tasking). However, especially given the various ofce space layouts, this
is not always applicable as can be seen in the following example, observed in company S and R:
5.3 Reducing Context Switches 37
While the ofce space in company S was usually quiet with only minimal background noise, the
participants in company Rs ofce space faced constant background noise as there were always
some co-workers discussing something. This led the participants (R1, R2, R3, R4) sometimes to
stop working on their current task and join a nearby background discussion, even if it was just
some private talking. Contrary, participants in company T have their own ofces, and can close
the door if they need some quiet time to work focused.
Participants mentioned several strategies to avoid distractions and interruptions, such as lis-
tening to music to eliminate the background noise and shutting off notications for new emails
or instant messaging alerts. Listening to music or constant background noise (e.g. whistling
birds or the noise in a coffee shop
2
) could not only improve a developers focus and concentra-
tion [MZC12], but also be a hint to others not to interrupt a developer, as practiced in company
R. One survey participant even mentioned his team is using an explicit indicator to avoid work
disruptions by others at certain times:
[. . . ] all devs in our team also have a physical light on top of our monitors that reects our Lync
3
status,
so people walking by can see not to disturb. This has been really useful in reducing random interruptions.
(MS5)
In general, participants take only very few actions to avoid distractions and interruptions, even
though they are aware of a wide variety of tools and tips, such as closing the email client, shut-
ting off notications, setting the instant messaging status to do not disturb, muting the smart-
phone, and closing the ofce door, if possible. These low-effort actions could help a developer to
work more focused, with fewer distractions and interruptions. A retrospection of the developers
workday, as described in section 5.2, showing blocks of focus, interruptions, and other context
switches, could help the developer to better identify when he is often distracted or interrupted
and to minimize resulting context switches.
A possible approach to minimize distractions and interruptions could be a tool which signals
co-workers when the developer is in a block of focus, the time when the cost of a context switch is
higher. Based on the assumption that a developer can only focus for a limited period of time and
the previously described Pomodoro Technique, the workday of a developer could be separated
into 25 minutes of focused work blocks, followed by short breaks of 5 to 10 minutes. These blocks
should be communicated with co-workers through the shared calendar and a light on top of the
monitor in case of an open plan ofce or in front of the closed ofce door, where possible. The
developer himself could also be reminded to focus and not to get distracted, by showing the
status light on his computers task bar. During focused work blocks, the tool should display a red
light and should automatically take actions to minimize the chance for context switches caused
by distractions or interruptions, such as setting the instant messaging clients status to do not
disturb, blocking work unrelated websites, or hiding notications for new emails. A green light
during breaks signals co-workers that they are allowed to interrupt and ask questions. In the
future, we would like to investigate if this tool succeeds in aiding developers to focus better and
be interrupted less frequently, while the developer is still following his duties in the team, such
as helping co-workers.
2
For example done via Noisli (noisli.com, veried 05/06/14), which praises itself as a background noise and color
generator for working and relaxing.
3
Microsoft Lync automatically adjusts the status to do not disturb if the developer is in a meeting (based on his
calendar) or has a call (phone call or VoIp call) to help avoid unnecessary interruptions.
Another approach could be to detect the best time to interrupt a developer and to display
this information to co-workers. Study participants mentioned various situations when an inter-
ruption would have the least negative effect on their productivity, such as when they are doing
work unrelated stuff, waiting for a build to complete, or answering emails. On the other hand,
our results and related work (e.g. [MICJ14]) indicate that a developer should not be interrupted
during blocks of high focus, during meetings or phone calls, if he has a high workload or is near
a deadline, or during specic activities which require full focus, such as coding, debugging, or
writing. This information could be used to visually show every developer whether it is a good
time to interrupt a co-worker with a question or not, e.g. with a light similar to the previously de-
scribed approach. This tool could prevent interruptions at time of full focus, while still ensuring
the teams awareness of each others work and the co-workers questions are being answered.
Task Resumption There are also situations, where a co-worker cannot avoid to interrupt
another developer, for example in case of an unexpected urgent bug. Even though participants
mentioned having difculties with resuming their tasks and are aware of their productivity loss
due to the time they need to resume the interrupted task, Ko et al. reported an average of 15
minutes [KAP
+
07], no participant mentioned using any task resumption tool. Task resumption is
widely discussed in research with respect to productivity (e.g. [PD10,CHW04] and there are many
tools available that would allow for a faster task resumption (e.g. [KM06, RWW05, DDJ
+
05]). It is
up to future work to nd the reason for this.
Chapter 6
Conclusion
There are several ways to address the gap between the increasing demand for software and lack of
supply. In this paper, we present one way to address supply: how we might improve the produc-
tivity of software developers? In doing so, we provide results from a survey with 379 professional
software developers and an in-person observation study with 11 professional developers in three
different companies. The survey results show that while coding was considered highly produc-
tive by most participants, there are several activities, such as meetings and handling emails that
are more difcult for developers to assess with respect to productivity. The results also show that
while progress made on work items is considered as one of the better measurements to assess pro-
ductivity, there is no simple and single best measurement to use. Developers also like to organize
their work to get in the ow so as to have few interruptions and context switches. Interestingly,
the observation data we collected paints a different picture, showing that developers experience
a high number of switches in their work, switching tasks every 6.2 minutes and activities every
1.6 minutes. The reason why developers still felt productive is the varying cost associated with
these varying forms of context switches. For example, we observed participants often switching
to simple tasks, such as reviewing code for 30 seconds or answering an email, without apparent
signicant impact to the primary task, such as xing a bug.
Based on this data, we propose a number of ways to improve a developers productivity
through tool support and the sharing of participants best practices. We propose a retrospec-
tion that stresses on focused work, progress on tasks, and work related versus work unrelated
activities, combined with tracked measures, such as activity on the computer and tasks worked
on, and compared to personalized activity related goals. Seeing uctuations in an abstracted mea-
surement, similar to the Nike+ Fuel, may provide a developer with sufcient support to retrospect
on how work was performed, particularly if detailed information could be provided. A reection
of the data in combination with suggestions at the right time, as suggested by Fogg [Fog03] may
help a developer to change his behavior towards improving productivity. In future work we will
develop the approach and evaluate it to nd out how well the idea serves the described purpose,
how well it is accepted by the users, and how and what kind of behavior changes it can induce.
Additionally, we investigate actions to reduce context switches caused by the developer himself
and external factors, such as co-workers or customers, and discuss the participants goal setting
best practice.
40 Chapter 6. Conclusion
Bibliography
[All03] David Allen. Getting Things Done. The Art of Stress-Free Productivity. 2003.
[And] M. Andreessen. Why software is eating the world. The Wall Street Journal. August 20,
2011.
[BA04] K. Beck and C. Andres. Extreme programming explained: embrace change. Addison-
Wesley, 2004.
[Boe87] Barry W. Boehm. Improving software productivity. volume 20, pages 4357. IEEE,
1987.
[Bro87] Frederick P. Brooks, Jr. No Silver Bullet Essence and Accidents of Software Engineer-
ing. Computer, 20(0):1019, 1987.
[BS08] Andrew Begel and Beth Simon. Novice software developers, all over again. In Pro-
ceedings of the Fourth International Workshop on Computing Education Research, ICER 08,
pages 314. ACM, 2008.
[BSSS
+
07] Dena M. Bravata, Crystal Smith-Spangler, Vandana Sundaram, Allison L. Gienger,
Nancy Lin, Robyn Lewis, Christopher D. Stave, Ingram Olkin, and John R. Sirard. Us-
ing pedometers to increase physical activity and improve health: A systematic review.
Jama, 298(19):22962304, 2007.
[BSVW96] Joseph D. Blackburn, Gary D. Scudder, and Luk N. Van Wassenhove. Improving speed
and productivity of software development: a global survey of software developers.
IEEE Transactions on Software Engineering, 22(12):875885, 1996.
[BTS
+
13] Frank Bentley, Konrad Tollmar, Peter Stephenson, Laura Levy, Brian Jones, Scott
Robertson, Ed Price, Richard Catrambone, and Jeff Wilson. Health Mashups : Pre-
senting Statistical Patterns between Wellbeing Data and Context in Natural Language
to Promote Behavior Change. ACM Trans. Comput.-Hum. Interact., 20(5):30:130:27,
2013.
[BVvD12] Eric Bouwers, Joost Visser, and Arie van Deursen. Getting What You Measure. Queue,
10(5):17, 2012.
[Car06] David N. Card. The Challenge of Productivity Measurements. In Pacic Northwest
Software Quality Conference, pages 110, 2006.
42 BIBLIOGRAPHY
[CCH00] Mary Czerwinski, Edward Cutrell, and Eric Horvitz. Instant Messaging and Interrup-
tion: Inuence of Task Type on Performance. pages 356361, 2000.
[CHC08] Marcelo Cataldo, James D. Herbsleb, and Kathleen M. Carley. Socio-technical con-
gruence: A framework for assessing the impact of technical and work dependencies
on software development productivity. In Proceedings of the Second ACM-IEEE Interna-
tional Symposium on Empirical Software Engineering and Measurement, ESEM 08, pages
211. ACM, 2008.
[CHW04] Mary Czerwinski, Eric Horvitz, and Susan Wilhite. A diary study of task switching
and interruptions. In Proceedings of the SIGCHI Conference on Human Factors in Comput-
ing Systems, CHI 04, pages 175182. ACM, 2004.
[CKML09] Sunny Consolvo, Predrag Klasnja, David W. McDonald, and James A. Landay. Goal-
setting considerations for persuasive technologies that encourage physical activity. In
Proceedings of the 4th international Conference on Persuasive Technology, pages 8:18:8.
ACM, 2009.
[CMT
+
08] Sunny Consolvo, David W. McDonald, Tammy Toscos, Mike Y. Chen, Jon Froehlich,
Beverly Harrison, Predrag Klasnja, Anthony LaMarca, Louis LeGrand, Ryan Libby,
et al. Activity sensing in the wild: a eld trial of ubit garden. In Proceedings of the
SIGCHI Conference on Human Factors in Computing Systems, pages 17971806. ACM,
2008.
[cod] http://codealike.com. veried: 05/20/14.
[Coo14] Belle Beth Cooper. How to Measure Progress in Your Personal Goals: Daily, Weekly,
and Monthly. Bufferapp.com. March 5, 2014, 2014.
[DDJ
+
05] Anton N. Dragunov, Thomas G. Dietterich, Kevin Johnsrude, Matthew Mclaughlin,
Lida Li, Jonathan L. Herlocker, and Dearborn Hall. TaskTracer: A Desktop Environ-
ment to Support Multi-tasking Knowledge Workers. 2005.
[Dij72] Edsger W. Dijkstra. The humble programmer. Communications of the ACM, 15(10):859
866, 1972.
[DKMT96] Prem Devanbu, Sakke Karstu, Walclio Melo, and William Thomas. Analytical and
empirical evaluation of software reuse metrics. In Proceedings of the 18th International
Conference on Software Engineering, ICSE 96, pages 189199. IEEE, 1996.
[DL85] Tom DeMarco and Tim Lister. Programmer performance and the effects of the work-
place. In Proceedings of the 8th International Conference on Software Engineering, ICSE 85,
pages 268272. IEEE, 1985.
[DMG11] Laura Dabbish, Gloria Mark, and Vctor M. Gonzlez. Why do i keep interrupting my-
self?: Environment, habit and self-interruption. In Proceedings of the SIGCHI Conference
on Human Factors in Computing Systems, CHI 11, pages 31273130. ACM, 2011.
[dSR08] Cleidson R. B. de Souza and David F. Redmiles. An empirical study of software de-
velopers management of dependencies and changes. In Proceedings of the 30th Inter-
national Conference on Software Engineering, ICSE 08, pages 241250. ACM, 2008.
[ecl] http://eclipse.org/recommenders/incubators. veried: 05/20/14.
BIBLIOGRAPHY 43
[FHMZ14] Thomas Fritz, Elaine M. Huang, Gail C. Murphy, and Thomas Zimmermann. Per-
suasive Technology in the Real World: A Study of Long-Term Use of Activity Sensing
Devices for Fitness. In Proceedings of the International Conference on Human Factors in
Computing Systems, 2014.
[t] http://fitbit.com. veried: 05/20/14.
[Fog03] Brian J. Fogg. Persuasive Technology: Using Computers to Change What We Think and Do.
Interactive Technologies. Elsevier Science, 2003.
[fue] http://nike.com. veried: 05/20/14.
[GGR11] Mirta Galesic and Rocio Garcia-Retamero. Graph literacy: a cross-cultural compari-
son. Medical decision making: an international journal of the Society for Medical Decision
Making, 31(3):44457, 2011.
[Gib94] Wayt W. Gibbs. Softwares chronic crisis. Scientic American, 271(3):8694, 1994.
[GM04] Victor M. Gonzlez and Gloria Mark. "constant, constant, multi-tasking craziness":
Managing multiple working spheres. In Proceedings of the SIGCHI Conference on Human
Factors in Computing Systems, CHI 04, pages 113120. ACM, 2004.
[GWA14] Daniel Graziotin, Xiaofeng Wang, and Pekka Abrahamsson. Happy software devel-
opers solve problems better: psychological measurements in empirical software engi-
neering. PeerJ, 2:e289, 2014.
[HA05] Hanna Hulkko and Pekka Abrahamsson. A multiple case study on the impact of pair
programming on product quality. In Proceedings of the 27th International Conference on
Software Engineering, ICSE 05, pages 495504. ACM, 2005.
[Hum96a] Watts S. Humphrey. Introduction to the Personal Software Process. Addison-Wesley Pro-
fessional, rst edition, 1996.
[Hum96b] Watts S. Humphrey. Using a dened and measured personal software process. IEEE,
13(3):7788, 1996.
[IH07] Shamsi T Iqbal and Eric Horvitz. Disruption and Recovery of Computing Tasks : Field
Study , Analysis , and Directions. pages 677686, 2007.
[jaw] http://jawbone.com/up. veried: 05/20/14.
[JKA
+
03] Philip M. Johnson, Hongbing Kou, Joy Agustin, Christopher Chan, Carleton Moore, Ji-
tender Miglani, Shenyan Zhen, and William E. J. Doane. Beyond the personal software
process: Metrics collection and analysis for the differently disciplined. In Proceedings of
the 25th International Conference on Software Engineering, ICSE 03, pages 641646. IEEE,
2003.
[Jon94] Capers Jones. Software metrics: good, bad and missing. Computer, 27(9):98100, 1994.
[KAP
+
07] Andrew J. Ko, Forbes Ave, Pittsburgh Pa, Robert Deline, and Gina Venolia. Infor-
mation Needs in Collocated Software Development Teams. In Proceedings of the 29th
international conference on Software Engineering, pages 334353. IEEE Computer Society,
2007.
[KM06] Mik Kersten and Gail C. Murphy. Using task context to improve programmer produc-
tivity. In Proceedings of the 14th ACM SIGSOFT international symposium on Foundations
of software engineering, SIGSOFT 06/FSE-14, pages 111. ACM, 2006.
44 BIBLIOGRAPHY
[KMB
+
96] Richard B. Kieburtz, Laura McKinney, Jeffrey M. Bell, James Hook, Alex Kotov, Jeffrey
Lewis, Dino P. Oliva, Tim Sheard, Ira Smith, and Lisa Walton. A software engineering
experiment in software component generation. In Proceedings of the 18th International
Conference on Software Engineering, ICSE 96, pages 542552. IEEE, 1996.
[Kon14] Maria Konnikova. Goodnight. Sleep Clean. The New York Times. January 1, 2014,
2014.
[LDF10] Ian Li, Anind Dey, and Jodi Forlizzi. A stage-based model of personal informatics
systems. Proceedings of the 28th international conference on Human factors in computing
systems - CHI 10, pages 557566, 2010.
[LZ97] Jo Ann Lane and David Zubrow. Integrating measurement with improvement: An
action-oriented approach: Experience report. In Proceedings of the 19th International
Conference on Software Engineering, ICSE 97, pages 380389. ACM, 1997.
[MFH02] Audris Mockus, Roy T. Fielding, and James D. Herbsleb. Two case studies of open
source software development: Apache and mozilla. ACM Transactions on Software En-
gineering and Methodology, 11(3):309346, 2002.
[MFMZ14] Andr N Meyer, Thomas Fritz, Gail C Murphy, and Thomas Zimmermann. Software
Developers Perceptions of Productivity. 2014. review pending.
[MGH05] Gloria Mark, Victor M. Gonzalez, and Justin Harris. No Task Left Behind? Examining
the Nature of Fragmented Work. 2005.
[MICJ14] Gloria Mark, Shamsi T. Iqbal, Mary Czerwinski, and Paul Johns. Bored Mondays and
Focused Afternoons: The Rhythm of Attention and Online Activity in the Workplace.
2014.
[Min80] H Mintzberg. The nature of managerial work. Theory of management policy series.
Prentice-Hall, 1980.
[Mun12] Sean Munson. Mindfulness, reection, and persuasion in personal informatics. In
Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 2012.
[MZC12] Ravi Mehta, Rui (Juliet) Zhu, and Amar Cheema. Is Noise Always Bad? Exploring
the Effects of Ambient Noise on Creative Cognition. Journal of Consumer Research,
39(4):784799, December 2012.
[NHB11] Vu Nguyen, LiGuo Huang, and Barry Boehm. An analysis of trends in productivity
and cost drivers over years. In Proceedings of the 7th International Conference on Predictive
Models in Software Engineering, Promise 11, pages 3:13:10. ACM, 2011.
[NR69] Peter Naur and Brian Randell. Software engineering: Report of a conference spon-
sored by the nato science committee. Scientic Affairs Division, NATO, 1969.
[PD10] Chris Parnin and Robert DeLine. Evaluating cues for resuming interrupted program-
ming tasks. Proceedings of the 28th international conference on Human factors in computing
systems - CHI 10, page 93, 2010.
[pom] http://pomodorotechnique.com. veried: 05/06/14.
[PSHH04] Allen Parrish, Randy Smith, David Hale, and Joanne Hale. AField Study of Developer
Pairs: Productivity Impacts and Implications. IEEE Software, 21(5):7679, 2004.
BIBLIOGRAPHY 45
[PSV94] Dewayne E. Perry, Nancy A. Staudenmayer, and Lawrence G. Votta. People, organi-
zations, and process improvement. Software, IEEE, 11(4):3645, 1994.
[res] http://rescuetime.com. veried: 05/20/14.
[RRMC14] John Rooksby, Mattias Rost, Alistair Morrison, and MatthewChalmers Chalmers. Per-
sonal tracking as lived informatics. In Proceedings of the 32Nd Annual ACM Conference
on Human Factors in Computing Systems, CHI 14, pages 11631172. ACM, 2014.
[RTKM12] Tobias Roehm, Rebecca Tiarks, Rainer Koschke, and Walid Maalej. How do profes-
sional developers comprehend software? In Proceedings of the 2012 International Con-
ference on Software Engineering, ICSE 2012, pages 255265. IEEE, 2012.
[RWW05] Martin P. Robillard and Frdric Weigand-Warr. Concernmapper: Simple view-based
separation of scattered concerns. In Proceedings of the 2005 OOPSLA Workshop on Eclipse
Technology eXchange, eclipse 05, pages 6569. ACM, 2005.
[SMDV06] Jonathan Sillito, Gail C. Murphy, and Kris De Volder. Questions programmers ask
during software evolution tasks. In Proceedings of the 14th ACM SIGSOFT International
Symposium on Foundations of Software Engineering, SIGSOFT 06/FSE-14, pages 2334.
ACM, 2006.
[Spr84] Lee S. Sproull. The nature of managerial attention. 1:927, 1984.
[TS10] Christoph Treude and Margaret-Anne Storey. Awareness 2.0: Staying Aware of
Projects , Developers and Tasks using Dashboards and Feeds. In ICSE 10, pages 365
374, 2010.
[US08] Medha Umarji and Carolyn Seaman. Why do programmers avoid metrics? Proceedings
of the Second ACM-IEEE international symposium on Empirical software engineering and
measurement - ESEM 08, page 129, 2008.
[Vra14] Alina Vrabie. Take advantage of productivity peaks and nd your daily rhythm.
Sandglaz Blog. February 20, 2014, 2014.
[WMT08] Sally Wehmeier, Colin McIntosh, and Johanna Turnbull. Oxford Advanced Learners
Dictionary. Oxford University Press, 2008.
[WR08] Stefan Wagner and Melanie Ruhe. A systematic review of productivity factors in soft-
ware development. Technical report, State Key Laboratory of Computer Science, In-
stitute of Software, 2008.
[ZM10] Minghui Zhou and Audris Mockus. Developer uency: Achieving true mastery in
software projects. In Proceedings of the Eighteenth ACM SIGSOFT International Sympo-
sium on Foundations of Software Engineering, FSE 10, pages 137146. ACM, 2010.
Contents of the CD-ROM
Zusfsg.txt
German version of the abstract of this thesis.
Abstract.txt
English version of the abstract of this thesis.
MasterThesis.pdf
Copy of this thesis.
Survey.pdf
Online survey questionnaire.
Interview.pdf
Interview protocol.
ObservationAllSessions.pdf
Developers activity and task switches in the two observation sessions.
Online Survey Questionnaire
The following pages show the survey we run online and within Microsoft with software devel-
opers.
Introduction to the participant
Dear reader,
Are there days when your development work goes well and days when you just cannot seem to
get anything done? We invite you to participate in our survey about your development work and
how you track and improve it. Our aim is to create tools to help you better reect and improve
on your development work.
The following survey will take you about 15 minutes of your time. With your participation
you get the chance to enter our lottery to win one of two Amazon gift certicates with a value
of $200 each.
We will keep your survey responses anonymous. We will NOT attribute answers to any par-
ticular participant. At the end of the survey, you are asked to insert your mail address voluntarily
to contact you in case you want to participate in the lottery and/or in case you want us to email
you the survey results.
We would greatly appreciate your participation!
50 Chapter . Online Survey Questionnaire
Survey
Questions about your Background
1. What is the size of the project you work for (in people)?
1-20 (Radio Box)
21-50 (Radio Box)
51-100 (Radio Box)
100+ (Radio Box)
2. Do you mostly have...
. . . open source project experience? (Radio Box)
. . . closed source project experience? (Radio Box)
3. Which country are you working in? (Text Box)
4. What best describes your primary work area?
Development (Radio Box)
Test (Radio Box)
Project Management (Radio Box)
Other Engineer (Radio Box)
Other Non-Engineer (Radio Box)
5. Which of the following best describes your role?
Individual Contributor (Radio Box)
Lead (Radio Box)
Architect (Radio Box)
Manager (Radio Box)
Executive (Radio Box)
Other (Radio Box)
6. How many years of software development experience do you have? (Text Box)
7. How many years of professional software development experience do you have? (Text Box)
8. What are the 5 software applications you use most during your workday? (5 Text Boxes)
Productivity
9. Please complete the following sentence in up to three ways:
I have a productive workday when. . . (3 Text Boxes)
10. Are you satised with your productivity of your prior workday?
very unsatised (Radio Box)
unsatised (Radio Box)
undecided (Radio Box)
satised (Radio Box)
very satised (Radio Box)
51
11. Are you satised with your productivity last week?
very unsatised (Radio Box)
unsatised (Radio Box)
undecided (Radio Box)
satised (Radio Box)
very satised (Radio Box)
12. How did you assess if you were productive last week (for the previous questions)?(Text Box)
13. Which activities do you consider particularly productive in a workday?(Text Box)
14. Which activities do you consider less productive in a workday?(Text Box)
Goal Setting and Monitoring
15. Do you usually set yourself personal goals for how much you will accomplish in your soft-
ware development project(s)?
You can select as many answers as you want.
Yes, daily goals. (Check Box)
Yes, weekly goals. (Check Box)
Yes, yearly goals. (Check Box)
No. (Check Box)
16. (if yes in question 15) What goals do you set yourself?
Please name example goals and also state if you set yourself the goals on a daily, weekly or yearly
basis. (Text Box)
17. (if yes in question 15) Do you monitor your goals and if so how do you monitor your goals
to see if you achieve(d) them?
We are interested in techniques, tools, methods, etc. (Text Box)
18. (if yes in question 15) Do you think that monitoring your work has any effect on your pro-
ductivity? Why do you think so and what are the effects? (Text Box)
19. Does your company set goals that you have to achieve in your software development work?
You can select as many answers as you want.
Yes, daily goals. (Check Box)
Yes, weekly goals. (Check Box)
Yes, yearly goals. (Check Box)
No. (Check Box)
20. (if yes in question 16) What kind of goals does your company set?
Please also state if the goals are on a daily, weekly or yearly basis. (Text Box)
52 Chapter . Online Survey Questionnaire
Goal Setting and Monitoring
21. Knowing the following would help me assess my personal productivity.
(1 = strongly disagree, 2 = disagree, 3 = neutral, 4 = agree, 5 = strongly agree)
Goals / Measurements 1 2 3 4 5
One X per Line
Changes and Tests
The number of commits I made.
The number of lines of code that I changed per day.
The number of code elements (e.g. packages or classes) that I changed.
The number of code elements that I changed for the rst time.
The time that I spent writing code.
The time that I spent in each code project or package.
The number of test cases I wrote.
The number of test cases I wrote that subsequently failed.
The number of API method I learned each day.
Email, Meetings, and Browsing
The number of emails I wrote.
The time it took me on average to respond to email.
The time I spent in meetings.
The number of meetings I attended.
The time that I spent browsing the web for work related information.
The time that I spent browsing the web for non-work matters during work.
Work items and Code Reviews
The number of work items (tasks, bugs) I closed.
The number of work items I created.
The number of work items I created that were xed.
The time I have spent on each work item.
The number of code reviews Ive contributed to.
The number of code reviews Ive signed off.
The time it takes me on average to sign off on code reviews.
The time I spend reviewing code.
Productivity Revisited
22. What information do you wish you could measure to help you meet your goals and/or to
improve your productivity?(Text Box)
23. What techniques do you use to be more productive? (Text Box)
24. How does a productive day, in comparison to an unproductive one, affect your. . .
. . . happiness: increases, no change, decreases (Radio Boxes)
53
. . . motivation: increases, no change, decreases (Radio Boxes)
. . . mood: increases, no change, decreases (Radio Boxes)
. . . concentration: increases, no change, decreases (Radio Boxes)
25. Assume we built a tool to monitor your productivity. What should it look like?
We are looking for possible concepts, features, functionality, looks, usage, etc.
26. Are you interested in the results as soon as they are published?
Yes (Radio Box)
No (Radio Box)
27. Are you interested in taking part in our lottery to win one of two Amazon gift certicates
with a value of $200 each?
Yes (Radio Box)
No (Radio Box)
28. Please insert your email address here in case you are interested in the results and/or want to
participate in our lottery. We will not give it to any third party nor will it be used to interpret
the data of the survey. (Text Box)
Thank you very much for your time and valuable help!
Observation Log
The following table is an example of an observation log, the author of this thesis created during
the observation of 11 participants from three different companies.
Created Task
Dura-
tion
Task Description Task
Num-
ber
Application Activity Category
09:29:06 00:00:48 EditorApp7: modies code 1 EditorApp7 Dev: Code
09:29:54 00:00:06 ConsoleApp1: builds project 1 ConsoleApp1 Dev: TestingAppli-
cation
09:30:00 00:00:21 EditorApp7: modies code 1 EditorApp7 Dev: Code
09:30:21 00:00:12 PlanningApp1: looks at task (issue) 1 PlanningApp1 Planning
09:30:33 00:00:07 EditorApp7: looks at code 1 EditorApp7 Dev: Code
09:32:32 00:00:16 ConsoleApp1: builds project 1 ConsoleApp1 Dev: TestingAppli-
cation
09:32:48 00:00:03 PlanningApp1: looks at task (issue) 1 PlanningApp1 Planning
09:32:51 00:00:27 ConsoleApp1: commits code 1 ConsoleApp1 Dev: TestingAppli-
cation
09:33:18 00:00:19 VcsApp1: looks at changes he made 1 VcsApp1 Dev: VC
09:33:45 00:00:53 PlanningApp1: updates task, needs
review (adds revision number)
1 PlanningApp1 Planning
09:34:38 00:00:29 PlanningApp1: looks at Dashboard
(open work items)
1 PlanningApp1 Planning
09:35:07 00:01:22 EmailApp4: checks new mail 2 EmailApp4 Email
09:36:29 00:01:06 None: checks task list on paper (in-
terrupted by Developer1)
1 None Planning
09:37:35 00:11:44 None: Discusses a specic code
problem that Developer1 currently
faces
2 None MeetingInformal
09:49:19 00:26:32 EditorApp8: seeks through code
while talking to Developer1 (Devel-
oper1 leaves)
3 EditorApp8 MeetingInformal
10:15:51 00:04:07 IdeApp6: (back on task 1) looks at
code
1 IdeApp6 Dev: Code
10:19:58 00:41:13 IdeApp6: modies code (starts lis-
tening to music)
1 IdeApp6 Dev: Code
Interview Protocol
The following pages show the interview protocol of our semi-structured interview conducted
with 11 participants working for three different companies.
Hi . . . ,
Thank you for participating. The aim of this interview/study is to better understand how devel-
opers perceive and reect on their productivity, if at all, and is based on the survey results from
380 software developers. Our aim is to eventually create tools to help you better reect on your
development work.
General
What best describes your primary work area? (Development, Test, Project Management, Other En-
gineer, Other Non-Engineer)
Which of the following best describes your role? (Individual Contributor, Lead, Architect, Manager,
Executive, Other)
How many years of software development experience do you have?
How many years of professional software development experience do you have?
Productivity
1. Do you ever consider whether you were productive on a given day?
2. If so, how do you determine or reect on your productivity?
3. Do you ever consider productivity over longer periods of time, for example, a week, a month,
a sprint?
4. If so, how do you determine or reect on your productivity?
5. What days do you think were most productive last week and why?
58 Chapter . Interview Protocol
Work Items
6. Are you working on work items each day and are you using a tool for managing your work
items? (if not clear from the observation)
7. You worked on several/one work item during the observation sessions, is that common, or
what is a usual day for you with respect to work items?
(if we dont have the number of work items they resolved over the past weeks and the code check-ins they
made, ask them if they can query for it)
(have them look at the list/visualization of work items.)
8. Is the number of work items you resolve in a week a good indicator of your productivity? (why
/ why not) (e.g. on Wednesday, you completed the most work items. Was this your most
productive day of the week?)
9. In general, does the number of work items help you to understand your productivity? If yes,
how? Can you expand on your productivity last week and relate to work items when pos-
sible?
10. Do you look at the number of work items you resolve at the end of a day or week?
11. What inuences the number of resolved work items?
12. Is the number of code check-ins you make in a week a good indicator of your productivity?
13. Is the number of code check-ins you make in a day a good indicator of your productivity?
14. Do you look at the number of code check-ins you make at the end of a day or week?
15. Does it help your productivity if work items are planned beforehand?
16. How do unplanned work items/todos inuence your productivity?
17. Do you create or update a list of TODOs / goals for every day / week?
Meetings
18. During the observation study you were in no/some meetings, is that representative. Could
you maybe look at your calendar and tell me how many meetings do you have for the past
work week (5 days) and how long are they on average?
19. Is that a representative number or were the past 5 days particularly hectic or quiet?
20. How many informal meetings do you typically have in a day or week that are not captured
in the calendar?
21. How long are these informal meetings usually?
22. If you look at your calendar, are there examples of meetings that you consider productive and
why?
59
23. Are there examples of unproductive meetings and why do you consider them as unproduc-
tive? (e.g. # of participants, duration, duration of planning, status/administrative/. . . , . . . )
24. How about the informal meetings, when are they rather productive or unproductive and
why?
25. How many meetings do you consider reasonable for a single day and is there a number when
they start to really decrease your productivity?
26. Do you schedule time for working by yourself in your calendar?
27. (if observed) You got a meeting invitation (notication) during the observation. Do you get a
lot of these? How do you decide whether to accept or reject a meeting invite?
(if not observed) Do you get a lot of meeting requests (notications)? How do you decide
whether to accept or reject these?
28. How do you decide whether or not its worth it looking at the meeting request and interrupt-
ing your work ow?
29. When / how do you usually handle these incoming requests?
Emails
30. How many emails to you approximately receive in a day?
31. How do you typically handle emails? Do you use any techniques to handle the emails, e.g.
do you have any lters or other rules set up?
32. How much time do you spend on checking and answering emails each day?
33. When do you consider handling emails productive, do you have any examples?
34. When do you consider handling emails unproductive, do you have any examples?
35. How often do you check your emails?
36. Do you try and block the handling of your emails or do you try and answer every time a new
email comes in?
37. (if observed) You got an email notication during the observation. Howdo you decide whether
to look at it or not?//(if not observed) Do you have email notications turned on? If you get
an email notication, how do you decide whether to look at it in more detail or not?
38. Do you have any other notications turned on and how do you handle those (e.g. Twitter,
Facebook,. . . )?
60 Chapter . Interview Protocol
Context Switches
39. Do you consider the last session productive? Why?
40. How would you dene a context switch in your work?
41. What are examples of context switches and what are the reasons for context switches?
42. Could you give me a concrete example of a context switch from the previous session?
43. Here is a quick overview of the activities we noted together with the context switches. Is that
accurate or are there any context switches missing or should not be considered as such?
44. Do you think that you usually have more context switches than in the observed session or are
these representative?
45. Are there cases in which context switches are necessary and benecial?
46. Are there cases in which context switches are bad?
47. Is the number of context switches you experience related to your productivity (e.g. the
more switches, the less productive you are)? (Do you consider periods with fewer context
switches more productive?)
48. Do you consider times in which you have no switches and are focused on one task particularly
productive? How long are these periods of focus for you usually (if not interrupted)?
49. How important is it for you to work on only one task at a time? (i.e. now interruptions, no
multi-tasking)
50. In your own opinion, how long can a context switch (e.g. an interruption) be, without majorly
harming your productivity?
51. Are you trying to avoid context switches and if so how?
52. How do self-interruptions (e.g. switching to a non-work related website such as a news web-
site) inuence your productivity?
53. What else affects your productivity?
More General (if there is time)
54. From the survey we see, that motivation, happiness, mood and concentration increases the
productivity. Do you agree, why and is there anything you do about it?
55. How does having good and enough sleep inuence your productivity?
56. What inuence has your working environment (e.g. infrastructure, work place, self-destined
working times) on your productivity?
57. How do deadlines and time pressure affect you and your productivity?

MasterThesis PDF

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

MasterThesis PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Master Thesis

June 19, 2014

number of tasks per month [ZM10],

number of source lines of code per hour [DKMT96],

number of function points per month [Jon94],

number of lines of code per person month of coding effort [BSVW96],

ratio of produced logical code lines and spent effort [HA05],

total equivalent lines of code per person-month [NHB11],

Das könnte Ihnen auch gefallen