What happens when software developers are (un)happy

Abstract

The growing literature on affect among software developers mostly reports on the linkage between happiness, software quality, and developer productivity. Understanding happiness and unhappiness in all its components -- positive and negative emotions and moods -- is an attractive and important endeavour. Scholars in industrial and organizational psychology have suggested that understanding happiness and unhappiness could lead to cost-effective ways of enhancing working conditions, job performance, and to limiting the occurrence of psychological disorders. Our comprehension of the consequences of (un)happiness among developers is still too shallow, being mainly expressed in terms of development productivity and software quality. In this paper, we study what happens when developers are happy and not happy. Qualitative data analysis of responses given by 317 questionnaire participants identified 42 consequences of unhappiness and 32 of happiness. We found consequences of happiness and unhappiness that are beneficial and detrimental for developers' mental well-being, the software development process, and the produced artefacts. Our classification scheme, available as open data enables new happiness research opportunities of cause-effect type, and it can act as a guideline for practitioners for identifying damaging effects of unhappiness and for fostering happiness on the job.

Full text

arXiv:1707.00432v1 [cs.SE] 3 Jul 2017
What happens when software developers are (un)happy
Daniel Graziotina, Fabian Fagerholmb, Xiaofeng Wangc, Pekka Abrahamssond
aInstitute of Software Technology, University of Stuttgart, Germany
bDepartment of Computer Science, University of Helsinki, Finland
cFaculty of Computer Science, Free University of Bozen-Bolzano, Italy
dDepartment of Computer and Information Science (IDI), NTNU, Trondheim, Norway
Abstract
The growing literature on affect among software developers mostly reports on the linkage between happiness, software
quality, and developer productivity. Understanding happiness and unhappiness in all its components – positive and
negative emotions and moods – is an attractive and important endeavour. Scholars in industrial and organizational
psychology have suggested that understanding happiness and unhappiness could lead to cost-effective ways of enhancing
working conditions, job performance, and to limiting the occurrence of psychological disorders. Our comprehension of
the consequences of (un)happiness among developers is still too shallow, being mainly expressed in terms of development
productivity and software quality. In this paper, we study what happens when developers are happy and not happy.
Qualitative data analysis of responses given by 317 questionnaire participants identified 42 consequences of unhappiness
and 32 of happiness. We found consequences of happiness and unhappiness that are beneficial and detrimental for
developers’ mental well-being, the software development process, and the produced artefacts. Our classification scheme,
available as open data enables new happiness research opportunities of cause-effect type, and it can act as a guideline
for practitioners for identifying damaging effects of unhappiness and for fostering happiness on the job.
Keywords: behavioural software engineering, developer experience, human aspects, happiness, affect, emotion
1. Introduction
The idea of flourishing happiness among developers is
often promoted by software companies, which knowingly or
accidentally attempt to enact the happy-productive worker
thesis (Zelenski et al., 2008). The happiness of all stake-
holders involved in software development is an essential
element of company success (Denning, 2012). Recent re-
search within the scope of behavioural software engineer-
ing (Lenberg et al., 2015) has highlighted the relationship
between software developer happiness and work-related
constructs such as performance and productivity (Grazi-
otin et al., 2015a, 2014b,a; Fagerholm et al., 2015; M¨uller
and Fritz, 2015; Ortu et al., 2015), quality (Khan et al.,
2010; Destefanis et al., 2016), and the social interactions
between developers (Novielli et al., 2015; Fagerholm et al.,
2015). Most of the studies to date have investigated the
positive side of happiness.
While happiness, for the individual, is inherently sub-
jective, research shows that it can be studied ob jectively.
Objective happiness can be construed as the difference be-
tween experienced positive affect and experienced negative
Email addresses:
daniel.graziotin@informatik.uni-stuttgart.de (Daniel
Graziotin), fabian.fagerholm@helsinki.fi (Fabian Fagerholm),
xiaofeng.wang@unibz.it (Xiaofeng Wang), pekkaa@ntnu.no (Pekka
Abrahamsson)
affect (Diener et al., 1999; Kahneman, 1999). Thus, maxi-
mizing happiness may be achieved by either maximizing
positive experiences or minimizing negative experiences
(or both). Studying both happiness and unhappiness is
needed to more thoroughly understand the options and
opportunities for increasing net happiness.
Focusing on the negative may already be intuitive to
many developers. It is a common occurrence that de-
velopers share horror stories about their working experi-
ence (Graziotin et al., 2014c). Managers in the software
profession would benefit from greater understanding of the
nature and dynamics of unhappiness among developers,
and they could take action to prevent dysfunctional re-
sponses among employees (Vecchio, 2000). Further under-
standing of the benefits of limiting negative experiences on
the job in general has been called for (Diener et al., 1999).
We aim to contribute to improved working conditions
and quality of life for software developers by broadening
the understanding of the (un)happiness of software devel-
opers. We are conducting a series of studies using a large-
scale quantitative and qualitative survey of software de-
velopers. Through those studies, we seek to assess the
distribution of (un)happiness in the developer population,
the causes of (un)happiness, and what the consequences of
those experiences are. The study described in the present
article is part of that series, and focuses on the conse-
quences of (un)happiness, i.e., what software developers

consider to happen when they experience happiness or un-
happiness. We have previously reported on other parts
of the study series, first as a poster-preview of results re-
garding the consequences of unhappiness (Graziotin et al.,
2017d) which preceded a workshop paper on the same sub-
ject (Graziotin et al., 2017a). The present article is an
extension of the workshop paper. We have reported on
the (un)happiness distribution among software developers
and the experienced causes of unhappiness in a separate
paper (Graziotin et al., 2017b).
The present article extends the previously reported
findings on the consequences of unhappiness (Graziotin
et al., 2017a) by including consequences of happiness and
considering the two together. Specifically, we investigate
the following research questions:
RQ1: What are the experienced consequences of unhappi-
ness among software developers while developing software?
RQ2: What are the experienced consequences of happiness
among software developers while developing software?
We report 42 experienced consequences of unhappiness
and 32 of happiness that we identified. The consequences
concern developers themselves in the form of cognitive and
behavioural changes, and external outcomes related to the
software development process and artefacts.
2. Background and Related Work
What is happiness, and how can it be assessed? In-
tuitively, happiness is related to an individual’s sensing of
their own affect. In this section, we give a brief overview of
the concepts and theory related to affect, emotions, moods,
and happiness. We also discuss previous research on hap-
piness and related constructs in the area of software engi-
neering.
2.1. Theory of Affect and Happiness
Affect is widely agreed to be “a neurophysiological state
that is consciously accessible as a simple, non-reflective
feeling that is an integral blend of hedonic (pleasure – dis-
pleasure) and arousal (sleepy – activated) values” (Rus-
sell, 2003, p. 147). For the purposes of this paper, we
use the theory by Russell (2003), and we thus consider
affect to be the atomic unit upon which moods and emo-
tions are constructed. Following several other authors,
e.g. Fisher (2000) and Khan et al. (2010), we consider
moods to be prolonged, unattributed affect, while emotions
are interrelated events concerning a psychological object –
an episodic process, clearly bounded in time, where an
individual perceives their own affect.
From a hedonistic viewpoint, happiness is a sequence
of experiential episodes (Haybron, 2001) and being happy
(unhappy) is associated with frequent experiences of posi-
tive (negative) affect (Diener et al., 2010).1Frequent pos-
itive (negative) experiential episodes lead to feeling fre-
1Alternative views of happiness exist, e.g. Aristoteles’ eudaimo-
quent positive (negative) affect, leading to happiness (un-
happiness) represented by a positive (negative) affect bal-
ance (Diener et al., 2010). Happy individuals are those
who experience positive affect more often than negative,
and unhappy individuals are those who experience nega-
tive affect more often than positive. In summary, happy in-
dividuals have a positive affect balance and unhappy ones
have a negative affect balance (Lyubomirsky et al., 2005;
Diener et al., 2010).
2.2. Affect and Happiness in Software Engineering Research
A considerable increase in the interest of studying af-
fect and happiness among software developers is visible
over the last five years, although the research is in its in-
fancy; many theoretical and methodological issues remain
in software engineering research, as illustrated by Grazi-
otin et al. (2015c,b) and by Novielli et al. (2015).
Several studies have attempted to elucidate the com-
plex relationship between happiness (and more generally,
affect) and performance in the context of software devel-
opment. In a study of the affect associated with elicit-
ing requirements, investigating 65 user requirements from
two projects, high activation and low pleasure levels were
shown to be predictors of high versioning requirements
(Colomo-Palacios and Casado-Lumbreras, 2011). Pleasure
was increased over time with each new version, while acti-
vation decreased.
Theory-building is an important part of software engi-
neering research, and theories regarding affect can inform
further empirical studies. One such theory is an explana-
tory process theory of the impact of affect on development
performance (Graziotin et al., 2015a). The theory was
formed by a qualitative analysis of the interview data, com-
munications, and observations of two software developers
in the same project. The concept of attractors – affective
experiences that earn importance and priority to a devel-
oper’s cognitive system – was theorized to have the biggest
impact on development performance.
Another theory that relates affective experiences to
development performance is the Performance Alignment
Work theory (Fagerholm et al., 2015), which explains a
continuous cycle of becoming aware of, interpreting, and
adjusting to changing performance demands in and be-
yond the organisational environment that software devel-
opment teams are situated in. The theory also explains the
ingredients that practitioners consider necessary to form
and maintain high-performing teams, which are especially
adept at carrying out the cycle. The theory was formed
by a qualitative analysis of the interviews with 16 prac-
titioners in five companies. Affective factors are found
throughout the theory, especially in relation to motivators
nia: a person is happy because (s)he conducts a satisfactory life full
of quality (Haybron, 2005). A review of affect theories is given in
(Graziotin et al., 2015c) and the role of the centrality of affect and
happiness is discussed in (Graziotin et al., 2015a).
2

for high performance, and in the social processes of be-
coming and being part of a high-performing team with a
strong identity.
Correlational experiments have found a positive rela-
tionship between happiness and positive emotions arising
from a development task (Graziotin et al., 2014b,a), and
between problem-solving performance and development task
productivity (M¨uller and Fritz, 2015). Affect has also been
shown to impact debugging performance: in a controlled
experiment where participants were asked to write a trace
of algorithm execution, induced high pleasure and activa-
tion affect were found to be associated with high debugging
performance (Khan et al., 2010).
Further evidence for the link that developers experi-
ence between emotion and performance is provided in a
survey with 49 developers, assessing emotions they per-
ceived to influence their own productivity (Wrobel, 2013).
Positive affective states were perceived to be those that en-
hance development productivity. The negative affect most
prevalently perceived was frustration, which was also the
one perceived to deteriorate productivity the most. Ford
and Parnin (2015) have further explored frustration in soft-
ware engineering through interviews. 67% of 45 partici-
pants in their study reported frustration being a severe
issue. Some of the causes for frustration were found to
be related to a lack of a good mental model of the code,
learning curves of programming tools, too large task sizes,
the time required to adjust to new projects, lack of re-
sources, perceived lack of programming experience, inabil-
ity to complete problems perceived as simple within the
bounds of estimated effort, fear of failure, internal hurdles
and personal issues, limited time, and issues with peers.
In all the studies investigating the happiness of devel-
opers in different forms and its impact on performance,
the findings point to a positive relationship. It is similar
when software quality is concerned. A series of studies
using software repository mining found links between af-
fect, emotions, and politeness, and software quality (Ortu
et al., 2015; Destefanis et al., 2016; M¨antyl¨a et al., 2016).
Happiness in terms of frequent positive affect and positive
emotions was found to be associated with shorter issue fix-
ing time (Ortu et al., 2015). The level of arousal, which,
when high, is associated with anxiety and burnout, was
found to be associated with issue priority (M¨antyl¨a et al.,
2016). Politeness in requests for resolving issues was corre-
lated with shorter resolution time (Destefanis et al., 2016).
Finally, the present article is part of a series of arti-
cles examining a large data set concerning happiness and
unhappiness among software developers. We have given
a preview of the consequences of unhappiness in a poster
paper (Graziotin et al., 2017d) and expanded on the same
topic in a workshop paper (Graziotin et al., 2017a). We
found a set of experienced consequences of unhappiness,
including detrimental effects on developers’ mental well-
being, the software development process, and the produced
artefacts. The present paper expands on these results. In
addition, we have investigated the experienced causes of
unhappiness (Graziotin et al., 2017b). We found that the
distribution of (un)happiness among software developers,
in terms of a quantitative, well established instrument for
assessing happiness, pointed towards developers being a
slightly happy population, with happiness scores higher
than those reported for many other parts of the general
human population. Furthermore, we found more than 200
factors representing causes of unhappiness, including being
stuck in problem solving, time pressure, bad code quality
and coding practice, under-performing colleagues, and feel-
ing inadequate with the task.
In sum, the present state of research shows that happi-
ness and affective experiences play an important role for
software developers, and that they are intertwined with
software development performance and quality. Several re-
lationships between individual affects and outcomes have
been demonstrated. Still, the present research leaves sev-
eral questions unanswered. On one hand, there is insuffi-
cient empirically grounded theory to warrant inquiry into
larger sets of causational relationships. On the other hand,
the voice of software developers could be expressed more
clearly and fully; the understanding of software develop-
ers’ everyday experiences with the development activity
is incomplete. We extend the picture in this paper with
further perspectives on happiness and unhappiness among
software developers.
3. Method
The present study is part of a series of inquiries that
we conducted on the data from a large-scale survey of de-
velopers. The overall research project employs a mixed
research method, with elements of both quantitative and
qualitative research (Creswell, 2009). The present study,
however, is purely qualitative. In this section, we describe
both the overall research design as well as methodological
details relevant to the present article.
3.1. Sampling Strategy
We consider a software developer to be a person con-
cerned with any aspect of the software construction pro-
cess (including but not limited to research, analysis, de-
sign, programming, testing, and management activities),
for any purpose such as work, hobby, or passion. Since we
do not accurately know the number of software developers
in the world, nor how to reach them, finding a sample that
would generalise to the population of software developers is
a challenge. We used the GitHub social coding community
as an avenue for reaching software developers that would
represent the population of developers well enough, follow-
ing several previous studies (e.g., Gousios et al. (2016)).
GitHub has more than 30 million visitors each month (Doll,
2015) and is, as far as we can tell, the largest social cod-
ing community in the world. Software developers using
GitHub work on a wide variety of projects, ranging from
open source to proprietary software and from solo work to
work done in companies and communities.
3

We extracted a set of developer contacts from the GitHub
Archive (Grigorik, 2012), which stores public events occur-
ring in GitHub. We retrieved event data for a period of six
months, since we intended to reach developers who were
active at the time of our study, meanwhile the amount
of events during 6 months is sufficiently large to include
as many developers as we desired. We extracted email ad-
dresses, given names, company names, developer locations,
and the repository name associated with each event. We
extracted unique entries that provided an e-mail address,
resulting in a total of 456 283 entries of contact data, in-
cluding e-mail addresses, given names, company names,
and locations of the developers, as well as the repository
name related to the public activity. Considering expected
response rates, we sent invitations to 33 200 randomly se-
lected e-mail addresses in the contact set.
3.2. Survey Design
We designed a survey consisting of (1) questions re-
garding demographics, (2) one question with the Scale of
Positive and Negative Experience (SPANE) (Diener et al.,
2010) with 12 items assessing happiness, and (3) two open-
ended questions asking for experienced causes and conse-
quences of positive and negative affect when developing
software. The two open-ended questions asked developers
to recall a time when they were developing software and
were experiencing affects described by adjectives in the
SPANE instrument (separately for positive and negative
affects). Participants were then asked to describe the situ-
ation and provide details on what they believed could have
caused them to experience the feelings, as well as whether
and how their software development was influenced. The
questionnaire is described in an online appendix (Graziotin
et al., 2017c).
We piloted the questionnaire three times, each with 100
participants from our contact set. The pilots allowed us to
estimate and improve response rates by refining the ques-
tions and invitation email. No data from the pilots were
retained in the final data set and pilot participants did not
participate in the final round. The present article covers
the results related to the open-ended questions regarding
the consequences of positive and negative affect (i.e., hap-
piness and unhappiness) while developing software.
3.3. Analysis
We qualitatively analysed the cleaned data for the open-
ended questions. We developed a coding strategy, apply-
ing open coding, axial coding, and selective coding as de-
fined by Corbin and Strauss’ Grounded Theory (Corbin
and Strauss, 2008) as follows2. We began by coding conse-
quences of unhappiness. The first three authors each coded
the same set of 50 responses using a line-by-line strategy.
We then compared the coding structure and strategy and
2For a review and guidelines of Grounded Theory in software
engineering research, see (Stol et al., 2016)
reached an agreement, i.e., a shared axial coding scheme.
We took the individual developer as the starting point and
unit of observation and analysis, and based the construc-
tion of theoretical categories on a model (Curtis et al.,
1988) of constructs that are internal or external to the
developer. The internal category concerns the developer’s
own being, while the external category contains artefacts,
processes, and people as subcategories. We then divided
the data evenly among the first three researchers and pro-
ceeded to open code them. We finally merged the codes
and conducted a last round of selective coding.
Once we had finished coding consequences of unhappi-
ness, we took the resulting coding scheme, omitting the
detailed leaf categories, and created a “reversed” or “mir-
rored” set of categories (examples are shown in Table 1).
Using this as an initial coding scheme, we again divided
the data evenly among the first three researchers, and
open coded the entire data set, this time looking for conse-
quences of happiness. Each researcher inserted sub-categories
into the coding scheme as required. We then revisited
the coding scheme together, and reached an agreement,
producing a second shared axial coding scheme for conse-
quences of happiness. One researcher then selectively re-
coded the data that did not fit this coding scheme (only a
small number of instances needed re-coding), and the two
other researchers verified the coding. Another researcher
then made an additional coding pass to add some detail at
the leaf level of the coding scheme. Finally, the same re-
searcher revisited both coding schemes and recoded small
parts in order to keep categories at similar levels so that
the schemes would be comparable in terms of structure
and prevalence of in-text occurrences3.
The end result is thus two coding schemes that are com-
parable at the top levels and in terms of structure, while
still allowing for differing detailed categories on the more
granular level. The coding process also allowed us to keep
track of the chain of evidence at all times. An example il-
lustrating the coding process of the consequences of unhap-
piness is given in Table 2, also available online (Graziotin
et al., 2017c).
We note that we only included positive consequences
for the happiness part and negative consequences for the
unhappiness part. The reverse directions are not explored
in this paper. Throughout the process of coding, we moni-
tored our progress and further discussed the coding scheme
and strategy in frequent meetings. All qualitative coding
and analysis was done using NVIVO 11 ; some calculations
were made using Rand a standard spreadsheet and calcu-
lator.
3We note that this final adjustment means that the coding scheme
is slightly different from that reported in Graziotin et al. (2017a); this
is intentional.
4

Table 1: Examples of reversed categories in coding scheme.
Original category (from consequences of unhappiness) Reversed category (to consequences of happiness)
developer’s own being →low cognitive perf ormance developer’s own being →high cognitive performance
developer’s own being →low motivation developer’s own being →high motivation
developer’s own being →work withdrawal developer’s own being →high work engagement and perseverance
external consequences →artefact and working with arte fact →low
code quality
external consequenc es →artefact and working with artefact →high
code quality
external consequences →pro cess →low productivity external consequences →pro cess →high productivity
external consequences →pro cess →decreased process adherence external consequences →pro cess →increased process adherence
Table 2: Example of coding phases showing the chain of evidence. The first column contains a response fragment. The next three columns
show how three different researchers open coded the fragment. The fourth column shows how the open codes were merged during the
agreement phase. The remaining columns show the higher-level codes of the axial and selective coding phases.
Response fragment Open coding R1 Open Coding R2 Open Coding R3 Open Coding Merged Axial Coding Selective Coding
I am annoyed when
a coworkers lack of
programming
progress limits my
programming
progress.
Team member
not progressing
Waiting for
others to finish
their code
Coding
Collaboration
Coordination issue
Bad code written by
others
Process
Code and
coding
Process
Artefact and
working with
artefact
I am angry when
when I work on
code for a long time
and it does not
work. [. . . ]
Eventually I have to
walk away to reflect.
Staying on
current broken
code
Working for a
long time on
code that does
not work
Negative
outcome
Unexplained broken
code
Code and
coding
Work
withdrawal
Artefact and
working with
artefact
Individual
(Consequences)
I am anxious when I
am put in charge of
a broken product
and feel that
massive
restructuring is
required. I have to
justify the ma jor
destruction of
’working’ code.
Anxiety
Handling a
broken project
Feeling that
code must be
restructured Having to justify
code
restructuring
Working with
legacy
Anxiety
Bad code quality and
coding practices
Mental unease
or disorder
Code and
coding
Individual
(Consequences)
Artefact and
working with
artefact
5

4. Results
In this section, we summarize the results of our inves-
tigation. We first show descriptive statistics describing
the demographics of the participants. We then proceed to
the qualitative data related to our RQs. We summarise
the elicited consequences of unhappiness while developing
software first, then move to the consequences of happiness,
reflecting the order in which the analysis was performed.
4.1. Descriptive Statistics
A total of 2 220 individuals participated in the study.
1 318 provided data for the open questions. Out of these,
317 provided answers pertaining to positive consequences
of happiness or negative consequences of unhappiness.
Since we treated the response data for the two research
questions separately, the set of respondents for each ques-
tion is different. In total, there are 317 respondents in the
two data sets combined, counting each respondent only
once. 70 of the respondents (22%) occur in both data sets,
while 247 respondents (78%) occur only in one of the data
sets. The descriptive statistics for the the data is shown
in Table 3 and discussed below.
We obtained 181 valid and complete responses related
to RQ1, which resulted in 172 male participants (95%)
and 8 female (4%). The remaining participant indicated
other / prefer not to disclose for gender. The mean year
of birth was 1984 (standard deviation, sd = 8.27), while
the median was 1986. A wide range of nationalities was
represented, comprising 45 countries. 141 (78%) partici-
pants were professional software developers, 7% were stu-
dents, and 13% were in other roles (such as manager, CEO,
CTO, and academic researcher). The remaining partici-
pants were unemployed and not students. The participants
declared a mean of 8.22 years (sd = 7.83) of software de-
velopment working experience; the median was 5 years.
We obtained 206 valid and complete responses related
to RQ2. In that set, 195 participants were male (95%) and
9 were female (4%). The remaining two participants de-
clared their gender as other / prefer not to disclose. The
mean year of birth was 1985 (sd = 9.67), and the me-
dian was 1987. A wide range of nationalities was repre-
sented, with 53 countries. 153 (74%) participants were
professional software developers, 9% were students, and
16% had other roles (defined as above). The remaining
two participants (1%) were unemployed and not students.
The participants reported a mean of 8.23 years (sd = 8.9)
of software development working experience, with a me-
dian of 5 years.
What are the Experienced Consequences of Unhappiness
Among Software Developers While Developing Software?
We identified 250 coded instances related to the nega-
tive consequences of unhappiness. They were grouped into
a scheme with 42 categories. The structure of the scheme
is shown in Figure 1, which is also available as archived
open data (Graziotin et al., 2017c). The material was di-
vided into an internal category, labelled developer’s own
being (113 references), and the external categories process
(102) and artefact (35).
4.2. Internal Consequences—Developer’s Own Being
The factors related to the developer’s own being do not
demonstrate a clear structure. This to some extent reflects
the versatile states of mind of developers and the feelings
they could have while they develop software.
The most significant consequences of unhappiness for
the developers’ own being are: low cognitive performance,
mental unease or disorder, low motivation and work with-
drawal.
Low cognitive performance is a category to group
all those consequences related to low or inadequate mental
performance. Specific symptoms include low focus: “[...]
the negative feelings lead to not thinking things through as
clearly as I would have if the feeling of frustration was not
present”; cognitive skills dropping off: “My software dev
skills dropped off as I became more and more frustrated
until I eventually closed it off and came back the next day
to work on it ”; and general mental fatigue: “Getting frus-
trated and sloppy”.
The mental unease or disorder category collects all
those consequences that threaten mental health4. Apart
from general lingering negative feelings, the participants
reported that unhappiness while developing software is a
cause of, in order of frequency, anxiety: “These kinds of
situations make me feel panicky”; stress: “[. . . ] only rea-
son of my failure due of burnout”; self-doubt: “If I feel
particularly lost on a certain task, I may sometimes begin
to question my overall ability to be a good programmer ”;
and sadness and depression. Participants mentioned de-
pression as feeling depressed, e.g., “feels like a black fog
of depression surrounds you and the project” or “I get de-
pressed ”. In addition, feelings of being judged, frustra-
tion, lack of confidence in one’s ability, and (even) adverse
physical reaction, although mentioned only once as the
perceived consequences of unhappiness, do appear, and
manifest the extent of mental unease or disorder caused
by unhappy feelings.
Low motivation is also an important consequence of
unhappiness for software developers. Motivation is a set
of psychological processes that cause the mental activa-
tion, direction, and persistence of voluntary actions that
are goal directed (Mitchell, 1982). Motivation has been
the subject of study in software engineering literature (e.g,
Fran¸ca et al. (2014)), and we reported that affective ex-
periences are related to motivation even though they are
not the same construct (Graziotin et al., 2015b). The par-
ticipants were clear in stating that unhappiness leads to
4In this study, we report what the participants stated, but we re-
mind readers that only trained psychologists and psychiatrists should
treat or diagnose mental disorders.
6

Table 3: Descriptive statistics for the data obtained for each research question. N denotes the size of each data set. Percentages are relative
to the size of the data for each question. The data sets partly overlap; 70 data points (22%) are in both data sets.
Gender Year of birth Role Work experience (years)
RQ N Male Female Other Mean Median Std. dev. Countries Professional Student Unemployed Other Mean Median Std. dev.
1 181 172 (95%) 8 (4%) 1 (1%) 1984 1986 8.27 45 141 (78%) 12 (7%) 5 (3%) 23 (13%) 8.22 5 7.83
2 206 195 (95%) 9 (4%) 2 (1%) 1985 1987 9.67 53 153 (74%) 18 (9%) 2 (1%) 33 (16%) 8.23 5 8.9
Consequences of unhappiness (negative outcome) (250)
developer’s own being (113)
low cognitive performance (35)
low focus (16)
inadequate performance (12)
skills dropped off (3)
fatigue (2)
uncertain decision-making (2)
mental unease or disorder (28)
anxiety (7)
stress (7)
self-doubt (4)
lingering negative feelings (3)
sadness, depression (3)
adverse physical reaction (1)
feel being judged (1)
frustration (1)
unconfident in one’s ability (1)
lower motivation (21)
work withdrawal (18)
not being creative (4)
resentful of being in the situation (2)
being cautious (1)
lower reputation (1)
rushing (1)
undervalued (1)
unhealthy coping behaviour (1)
external consequences (137)
process (102)
low productivity (59)
delay (18)
decreased process adherence (12)
taking short cut (6)
missing documentation (2)
bad management (1)
decreased organization (1)
no methodology (1)
tightened-up communication (1)
unspecified consequence (8)
broken flow (5)
artefact and working with artefact (35)
low code quality (30)
discharging code (5)
Figure 1: Categories for consequences of unhappiness. The numbers indicate the amount of coded instances at each level, including sub-
categories.
7

low motivation for developing software, e.g., “[the unhap-
piness] has left me feeling very stupid and as a result I
have no leadership skills, no desire to participate and feel
like I’m being forced to code to live as a kind of punish-
ment. [. . . ] ”, or “Also, I’m working at a really slow pace
[. . . ] because I’m just not as engaged with the work”.
Work withdrawal is a very destructive consequence
of unhappiness, and it emerged often among the responses.
Work withdrawal is a family of behaviours that is defined
as employees’ attempts to remove themselves, either tem-
porarily or permanently, from quotidian work tasks (Miner
and Glomb, 2010). The gravity of this consequence ranged
from switching to another task, e.g., “[. . . ] you spend like
2 hours investigating on Google for a similar issue and
how it was resolved, you find nothing, desperation kicks in.
It clouds your mind and need to do other things to clear
it”, to considering quitting developing software, “I really
start to doubt myself and question whether I’m fit to be a
software developer in the first place”, or even, “I left the
company”.
Other consequences perceived by the participants in-
clude not being creative, “it is very difficult for me to do
any creative work when angry or unhappy”, resentful of be-
ing in the situation, being cautious, lower reputation, rush-
ing, undervalued, and unhealthy coping behaviour, such
as smoking excessively. Because of the low frequency of
mentions in the data, we do not elaborate on these conse-
quences further here.
4.3. External Consequences—Process
The category of process collects those unhappiness con-
sequences that are related to a software development pro-
cess, endeavour, or set of practices that is not explicitly
tied up to an artefact (see Section 4.4).
Low productivity is a category for grouping all conse-
quences of unhappiness related to performance and produc-
tivity losses5. The codes within this category were ranging
from very simple and clear “productivity drops”, “[nega-
tive experience] definitely makes me work slower ” to more
articulated “[unhappiness] made it harder or impossible to
come up with solutions or with good solutions”, “[. . . ], and
[the negative experience] slowed my progress because of the
negative feeling toward the feature”.
Unhappiness was reported to be causing delay in ex-
ecuting process activities: “In both cases [negative experi-
ences] the emotional toll on me caused delays to the project”.
Unhappiness causes glitches to communication activities
and a disorganized process: “Miscommunication and dis-
organization made it very difficult to meet deadlines ”.
Developers declared that unhappiness caused them to
have decreased process adherence, i.e., deviating from
the agreed set of practices. Specifically, unhappiness was
5See (Graziotin et al., 2015a) and (Fagerholm et al., 2015) for our
stance on a definition of productivity and performance in software
engineering.
reported to lead developers to compromise in terms of ac-
tions, in order to just get rid of the job: “In these instances
my development tended towards immediate and quick ‘ugly’
solutions”. Developers see the quality of their code com-
promised (Section 4.4) but also decide to take shortcuts
when enacting a software process, compromising method-
ology, good management, and the quality of the process
itself: “[. . . ] can lead to working long hours and trying
to find shortcuts. I’m sure this does not lead to the best
solution, just a quick one”. The process adherence can suf-
fer due to communication aspects, too: “my development
was influenced by [negative affect] in that it caused me to
tighten up communications and attempt to force resolution
of the difficulties”.
The broken flow category is related to the process de-
viation in terms of process unevenness and wasted time in
restarting tasks. The concept of flow has been defined by
Csikszentmihalyi (1997) as a state of intense attention and
concentration resulting from task-related skill and chal-
lenge being in balance. Flow has been investigated by
M¨uller and Fritz (2015) in the context of software devel-
opment. Unhappiness causes interruptions in developers’
flow, resulting in adverse effects on the process. As put by
a participant, ‘things like that [of unhappiness] often cause
long delays, or cause one getting out of the flow, making
it difficult to pick up the work again where one has left off.
”. Unhappiness and broken flow make developers stand up
and “[. . . ] make me qu it and take a break”; the feeling of
getting stuck is persistent.
4.4. External Consequences—Artefact-oriented
The category of artefact-oriented consequences groups
all those consequences that are directly related to a devel-
opment product, e.g., software code, requirements, and to
working with it. As expected by the foci of previous re-
search, the most important consequence of unhappiness of
software developers was low software quality.
Low code quality represents the consequences of un-
happiness of developers that are related to deterioration
of the artefacts’ quality. The participants reported that
“eventually [due to negative experiences], code quality can-
not be assured. So this will make my code messy and more
bug can be found in it”, but also mentioned making the
code less performant, or “As a result my code becomes
sloppier”. Moreover, participants also felt that they could
discharge quality practices, e.g., “[. . . ] so I cannot fol low
the standard design pattern”, as a way to cope with the
negative experiences.
Discharging code could be seen as an extreme case of
productivity and quality drop. We found some instances
of participants who destroyed the task-related codebase,
e.g., “I deleted the code that I was writing because I was a
bit angry”, up to deleting entire projects: “I have deleted
entire projects to start over with code that didn’t seem to
be going in a wrong direction”.
8

What are the Experienced Consequences of Happiness Among
Software Developers While Developing Software?
We now provide a summary of the elicited positive
consequences of happiness while developing software. We
identified a total of 340 coded instances related to the con-
sequences of happiness, They are grouped into 32 cate-
gories and sub-categories. The structure of the categories
is shown in Figure 2, and is available as archived open
data (Graziotin et al., 2017c). Consistent with the un-
happiness consequences, we defined an internal category,
developer’s own being (198 coded instances), and two ex-
ternal categories, process (104) and artefact (38).
4.5. Internal Consequences—Developer’s Own Being
Similar to those of unhappiness consequences, the set
of factors related to the developer’s own being is varied
and displays no clear structure. The most significant con-
sequences of happiness for the developer’s own being are:
high cognitive performance, high motivation, perceived
positive atmosphere, higher self-accomplishment, high work
engagement and perseverance, higher creativity and higher
self-confidence. Other less mentioned consequences include
being valued, being proud, and healthy coping behaviour.
High cognitive performance is a category grouping
all consequences related to high mental performance, such
as being focused: “My software development is influenced
because I can be more focused on my tasks and trying to
solve one problem over another ”; higher problem-solving
performance: “I mean, I can write codes and analyse prob-
lems quickly and with lesser or no unnecessary errors when
I’m not thinking of any negative thoughts”; higher men-
tal energy: “This influenced my work by making me more
alert, concentrated”; higher skills: “. . . felt that my skil l
has improved tremendously”; and higher learning abilities:
“It made me want to pursue a masters in Computer science
and learn interesting and clever ideas to solve problems”.
We excluded creativity from this category; while cognitive
performance is an important component of creativity, the
latter also requires divergent thinking and emotion plays
a different role than in more logical tasks (see, e.g., Baas
et al. (2008) and Davis (2009) for discussions on the emo-
tional aspects of creativity).
High motivation is an important consequence of hap-
piness for software developers. The participants stated
that increased motivation occurred as they were happy,
e.g., “When I write a bunch of code and compile/run it
and it works without any errors. Though, when that hap-
pens I also become a bit suspicious. I felt more motivated
to continue writing code at that point”.
Perceived positive atmosphere is an internal eval-
uation of the surrounding social context that participants
reported occurring with happiness. Participants reported
greater peace of mind: “it’s very comforting”; as well as
simply enjoying the moment: “. . . gives you the sense of
achievement and joy”.
Higher self-accomplishment refers to stronger or
more frequent feelings of having achieved something suc-
cessfully. With increased happiness during development,
respondents reported that they felt having performed some-
thing successfully: “The sense of accomplishment when fin-
ishing something that actually works is very rewarding ”.
High work engagement and perseverance was re-
ported to occur when respondents were happy. This means,
e.g., pushing forward with tasks: “I think I was more mo-
tivated to work harder the next few hours ”.
Higher creativity was also a reported result of hap-
piness. Participants reported finding it easier to come up
with new ideas and to think divergently: “This give you
energy [which] feed your creativity and you come up [with]
more crazy and wonderful ideas”.
Higher self-confidence means greater trust in one’s
personal abilities. This category includes both higher gen-
eral self-confidence as well as task-specific self-confidence
(self-efficacy). Participants expressed a shift in self-confi-
dence when they were happy, e.g.: “These situations en-
courage me to pick up tasks that I was afraid of before,
because they seemed to be too difficult”.
Being valued is another social evaluation experienced
by participants when being happy: “My boss said ‘You’re
the best’ and then gave me a hug and I said ‘nuh uh your
tha best’”.
Participants also reported being proud when they
were happy, both directed towards their work – “great
pride in the work I’ve just completed” – and directed to-
wards themselves – “I get more proud of myself ”.
Finally, one participant reported on another developer’s
happiness encouraging healthy coping behaviour: “[He]
has a definite positive effect on development, not just the
production side but also my attitude when dealing with neg-
ative issues”.
4.6. External Consequences—Process
Being in a happy mood was often associated by the
participants to several positive consequences closely re-
lated to software development processes. Among different
consequences, high productivity is the most frequently
listed one, followed by expediation,sustained flow,in-
creased collaboration and increased process adher-
ence.Creative process is also a perceived consequence
of happiness, though with one occurrence only.
The most noticeable positive consequence related to
process by far is high productivity, as put by several
participants, “When I have this [happy] feeling I can just
code for hours and hours”, “I felt that my productivity grew
while I was happy”, “The better my mood, the more pro-
ductive I am”. One participant described in more detail
such high productivity caused by happy mood: “I become
productive, focused and enjoy what I’m doing without wast-
ing hours looking here and there in the code to know how
things are hooked up together”. One interesting aspect of
this high productivity caused by being in a happy state is
9

Consequences of happiness (positive outcome) (340)
developer’s own being (198)
high cognitive performance (51)
being more focused (20)
higher problem-solving performance (12)
higher mental energy (11)
higher skills (6)
higher learning abilities (2)
high motivation (42)
perceived positive atmosphere (24)
peace of mind (13)
enjoying the moment (11)
higher self-accomplishment (23)
high work engagement and perseverance (20)
higher creativity (15)
higher self-confidence (13)
being valued (6)
being proud (3)
healthy coping behaviour (1)
external consequences (142)
process (104)
high productivity (61)
expediation (12)
sustained flow (12)
increased collaboration (12)
increased process adherence (6)
do things right (2)
write documentation (2)
follow best practice (1)
write tests (1)
creative process (1)
artefact and working with artefact (38)
high code quality (38)
Figure 2: Categories for consequences of happiness. The numbers indicate the amount of coded instances at each level, including sub-categories.
10

that the developers tend to take on undesired tasks. As
one participant admitted: “I think that when I’m in this
happy state I am more productive. The happier I am the
more likely I’ll be able to accomplish tasks that I’ve been
avoiding”. Another intriguing aspect is the long-term con-
sideration invoked by the happy state of mind: “I find that
when I feel this way [being happy], I’m actually more pro-
ductive going into the next task and I make better choices
in general for t he maintenance of the code long-term. [. . . ]
I’m more likely to comment code thoroughly”. However, a
few participants expressed the counter opinion, ether not
perceiving any productivity increase when they feel happy,
or perceiving it to a certain extent but cautioning that it
is “not for long”.
Expediation as a perceived consequence emphasises
that when developers feel good during development, tasks
can be sped up without sacrificing quality, and “it seems
more likely to reach my goals faster”. Meantime, devel-
opers can enter a state of a sustained flow. Developers
feel being in a state of flow, full of energy and with strong
focus. In such a state, they are “unaware of time passing ”.
They can “continue to code without anymore errors for the
rest of the day”, and “just knock out lines of code all day”,
with “dancing fingers, my code is like a rainbow”.
Happy developers can also mean more collaborative
team members, leading to increased collaboration. As
one participant put it, “when I feel good, I speak more with
my mate so better communication”. Positive feelings could
influence the practices that a team uses and promote good
manners where team members work with each other, in
turn making the interactions among team members enjoy-
able.
Being more self-disciplined, as indicated by increased
process adherence, is also perceived by the participants
as a consequence of being happy, as demonstrated by this
response: “when I am happy to work, I usually try new
things and follow best practices and standards as much as
possible”. The adherence to process is manifested espe-
cially when testing and documentation are concerned: “the
better I feel, I’m more likely to produce elegant code, with
tests and documentation”.
Creative process can also be a positive consequence
of developers being happy, as stated in this response: “if
[. . . ] I have a general good mood, the software process gets
to be creative and very good”.
4.7. External Consequences—Artefact-oriented
High code quality is the single most significant con-
sequence of happy feelings while developing software, as
perceived by the participants. A participant told a small
story about their work: “I was building an interface to
make two applicaitons talk. It was an exciting challenge
and my happy and positive feelings made me go above and
beyond to not only make it functional but I made the UX
nice too. I wanted the whole package to look polished and
not just functional”. Higher quality of code is generally
realized when the mood of developers is positive, because
they tend to make less mistakes, see solutions to prob-
lems more easily, and make new connections to improve
the quality of the code. A participant argued: “When I’m
in a good mood and I feel somehow positive, the codes I
write seems to be very neat and clean. I mean, I can write
codes and analyse problems quickly and with lesser or no
unnecessary errors”. As a result, the code is cleaner, more
readable, better commented and tested, and with less er-
rors and bugs.
5. Discussion
The main finding of our study is that software devel-
opers experience several consequences of unhappiness and
happiness, with most of the consequences of unhappiness
being external (55%) and most consequences of happiness
pertaining to the developer’s own being (58%) (internal
consequences). We may say that broadly speaking, devel-
opers more frequently consider their happiness to benefit
themselves, and their unhappiness to be detrimental to
others. However, this applies on the most general level
of our results, and examining the details reveals several
important findings. In this section, we first consider the
answers to our research questions, examine the implica-
tions of the research questions taken together, discuss the
limitations of the study, and provide recommendations for
practitioners and researchers.
5.1. Addressing the research questions
Consequences of Unhappiness. Our analysis to answer RQ1
resulted in 42 categories of negative consequences that de-
velopers experienced to stem from unhappiness. Many of
these have a detrimental impact on several important soft-
ware engineering outcomes. Productivity and performance
are the aspects which suffer most from unhappy developers.
When grouping codes for low cognitive performance and
process-related productivity, approximately 55% of the re-
lated in-text references deal with productivity and perfor-
mance drops. Those results are in line with and support
the related work in software engineering research (Grazi-
otin et al., 2015a, 2014b,a; M¨uller and Fritz, 2015; Khan
et al., 2010; Wrobel, 2013) which quantified the relation-
ship or attempted to explain the link.
Slightly more than half of the in-text occurrences (55%)
concern external consequences. Most of these relate to the
process of developing software. Unhappiness is reported
to result in unevenness in the process: low productivity,
delays, and broken flow. Unhappiness decreases develop-
ers’ adherence to the agreed process, resulting in taking
process-related shortcuts (i.e., to “cut corners”). These
deviations are often mentioned to cause issues in terms of
software quality. External consequences were also reported
on software artefacts, where, in addition to low code qual-
ity, discharging code was mentioned. While a few studies
have been conducted on the impact of developers’ affect on
software quality (e.g, Khan et al. (2010); Destefanis et al.
11

(2016); Ortu et al. (2015, 2016)), we encourage further re-
search on the matter.
Slightly less than half of the in-text occurrences (45%)
concern consequences for the developer’s own being (in-
ternal consequences). The most prevalent consequences in
this category are related to the cognitive performance of de-
velopers. Unhappiness takes its toll in terms of low focus,
inadequate performance, reduction of skills, fatigue, and
problems with decision-making. Such consequences hit di-
rectly at the core of the software development activity, as
it is inherently intellectual. The link to the external con-
sequences related to low productivity, decreased process
adherence, broken flow, and low quality appears obvious,
but would have to be confirmed in further studies.
Our results further show that unhappiness while per-
forming software development may be a source of several
mental-related issues that are known to be of detrimental
effect to the individual and the work environment. We
found situations of mental unease, e.g., low self-esteem,
high anxiety, burnout, and stress. Initial software engineer-
ing research on the latter two has started (e.g., M¨antyl¨a
et al. (2016)), but the related work in psychology is com-
prehensive and alarming in regards to how disruptive these
issues are on well-being. Furthermore, our data has also
shown mentions of possible mental disorders such as de-
pression4.
Unhappiness appears to also bring down motivation
among developers, which is a critical force in software en-
gineering activities (Fran¸ca et al., 2014). Negative experi-
ences and negative affect are also perceived to be causes of
work withdrawal. Psychology research has recently started
to investigate the role of affect in work withdrawal (e.g.,
Miner and Glomb (2010)), but we are not aware of related
software engineering research. Our analysis shows that de-
velopers may distance themselves from the task to which
their unhappiness relates, up to the point of quitting jobs.
Among the least mentioned categories, we wish to high-
light reduced creativity as a consequence of unhappiness.
Creativity has been considered beneficial and even required
in software development (see, e.g., Brooks (1975)). Its re-
duction should be considered problematic in many situa-
tions.
Consequences of Happiness. In our analysis for RQ2, we
found 32 categories of positive consequences of happiness.
Many of these have a positive impact on software engi-
neering outcomes. Higher productivity and performance
appear as aspects which benefit most from happiness. Ap-
proximately 33% of the related in-text references, cate-
gorised into high cognitive performance and process-related
productivity, deal with increased productivity and perfor-
mance. This strengthens the result obtained for RQ1: de-
velopers experience happiness as a productivity and perfor-
mance booster, and unhappiness has the opposite effect.
More than half of the consequences related to devel-
opers’ experiences of happiness (58%) had to do with the
developer’s own being. The most prevalent category is
high cognitive performance. Happy developers appear to
be more focused, have higher performance on problem-
solving, higher mental energy, higher skills, and to learn
better. Again, given the nature of the software develop-
ment task, these consequences are very desirable, and can
result in positive external outcomes.
Another prevalent category of consequences is high mo-
tivation, which participants reported experiencing due to
happiness. This suggests that influencing developers’ hap-
piness should be considered when the goal is to influence
their motivation. A perceived positive atmosphere, with
peace of mind and opportunities to enjoy the moment, are
factors contingent on the social environment. Fagerholm
et al. (2015) has previously linked a positive atmosphere
to high performance.
Other positive outcomes reported by our participants
include high work engagement and perseverance, higher
creativity, higher self-confidence, and being valued and
proud.
Less than half of the consequences related to happi-
ness (42%) were external. As with unhappiness, process-
related outcomes were most prevalent. Participants ex-
perienced high productivity, expediation, sustained flow,
increased collaboration, increased process adherence, and
a more creative process to result from happiness. This in-
dicates a more speedy, even process with more social ties
to other developers, and a stronger commitment to follow
the agreed process, including “doing things right”, writing
documentation, following best practice, and writing tests.
A smaller but still meaningful portion of the external
consequences had to do with the software artefact under
development. Here, participants exclusively discussed high
code quality as a consequence of happiness.
Comparing Consequences of Unhappiness and Happiness.
When comparing the results for the two research ques-
tions, some interesting insights emerge. Many of the con-
sequences have similar prevalence on both the happiness
and unhappiness side.
Categories in the developer’s own being have similar
prevalence across unhappiness and happiness. Both in ex-
perienced consequences of unhappiness and happiness, cog-
nitive performance is the most prevalent category, with
unhappiness reducing it and happiness increasing it. The
structure within those categories is also very similar for
both sides, e.g. low focus is first on the unhappiness side,
while being more focused is first on the happiness side.
Higher problem-solving performance does not have a coun-
terpart on the unhappiness side. This category could be
related to being stuck in problem-solving, which we have
previously reported as an important cause of unhappiness
(Graziotin et al., 2017b).
The second most prevalent consequence of unhappiness
is mental unease or disorder, with no direct counterpart on
the happiness side. Several other consequences might be
construed as mental well-being or positive mental health,
12

but no single consequence can be said to be the mirror
category.
Lower motivation is the third most prevalent conse-
quence of unhappiness and its opposite, high motivation,
the second most prevalent consequence of happiness. This
highlights its importance in developers’ experience of con-
sequences of both happiness and unhappiness.
The fourth most prevalent consequence of unhappiness,
and the fifth of happiness, are work withdrawal and high
work engagement and perseverance. These categories are
related to motivation, but the latter is more general.
The remaining positions in terms of prevalence are cre-
ativity (fifth, unhappiness, sixth, happiness) being cau-
tious – higher self-confidence (both on seventh place); un-
dervalued (tenth, unhappiness) – being valued (eighth, hap-
piness); unhealthy coping behaviour (eleventh, unhappi-
ness) – healthy coping behaviour (tenth, happiness).
Higher self-accomplishment has no direct counterpart
on the unhappiness side. This category pertains solely to
achievement and having reached something. Higher self-
confidence is a related category with no direct counterpart
on the unhappiness side. It is less connected to achieve-
ment, and although the two may influence each other,
they are separate. On the unhappiness side, self-doubt
and being cautious are similar categories, but higher self-
confidence is more specific: feeling safe and courageous to
engage in new or risky actions.
Among the external categories, the similarities in preva-
lence is also visible. Both in experienced consequences
of unhappiness and happiness, consequences for produc-
tivity are the most prevalent within the process category.
The process category on both sides have similar frequen-
cies (102 and 104, or 75% and 73% for unhappiness and
happiness, respectively) and the top codes have a similar
structure. One category on the happiness side without a
counterpart on the unhappiness side is increased collabo-
ration. Happiness could lead developers to reach out to
others more.
Artefact and working with artefact have similar fre-
quencies on both sides (38 and 35, or 27% and 26%, respec-
tively). On the happiness side, there is only one strong
sub-category. Software developers’ experiences of conse-
quences of (un)happiness related to the software artefact
appears to be largely connected to code quality.
Finally, we observe that only 22% of the respondents
in this study are in both the data set for experienced con-
sequences of happiness and unhappiness. This means that
the responses on happiness are, to a large extent, distinct
from the responses on unhappiness. There may be a ten-
dency among some respondents to recall and report more
on happiness, and among others to report more on unhap-
piness. If this is the case, personality may explain why
some respondents would focus more on one or the other.
Another possible explanation is respondent fatigue. How-
ever, judging from the overall responses, this does not seem
to be the case, as most respondents who provided an an-
swer to the first displayed open question also provided one
for the second. The content of the answers is the largest
determinant for whether a response was coded as express-
ing a consequence of happiness or unhappiness. We there-
fore suggest that personality should be taken into account
when studying and considering (un)happiness among soft-
ware developers.
5.2. Limitations
We elicited the experienced consequences of unhappi-
ness and happiness of software developers using a survey
approach and qualitative data analysis techniques. Whether
causality can be inferred from research approaches other
than controlled experiments, e.g., eliciting experiences from
introspection in the context of qualitative research, is a
matter of debate (Creswell, 2009; Djamba and Neuman,
2002; Gl¨aser and Laudel, 2013). However, several authors,
e.g., Gl¨aser and Laudel (2013), take the stance that quali-
tative data analysis can be used to infer causality from the
experience of human participants, provided that there is
a strong methodology for data gathering and analysis. In
our case, we followed Grounded Theory coding methodol-
ogy (Corbin and Strauss, 2008) in order to strengthen the
validity of our results. Furthermore, our research goal was
to elicit the consequences of unhappiness as experienced
by developers themselves. As the consequences come from
first-hand reports, we argue that they accurately represent
the respondents’ views. Our study does not imply any gen-
eral relationship between any specific consequences; only
experienced consequences of (un)happiness are claimed.
Our sample of software developers using GitHub is lim-
ited in size and with respect to representativeness of de-
velopers at large. Our dataset (see Section 3.1) contains
accounts with public activity during a six-month period.
This may result in a bias as developers who prefer not
to display their work in public would not be present in
the data set; nor would developers whose work is done in
companies’ internal systems. The six-month time period,
however, is less of an issue as very inactive developers are
of less interest to our study – but they may differ in terms
of how they view consequences of (un)happiness. Replica-
tion using different data sources and collection methods is
needed to validate our results in these scenarios.
It might be the case that the “GitHub population of
developers” is slightly younger than developers in general,
but to our knowledge no empirical evidence exists in ei-
ther direction. GitHub is a reliable source for obtaining
software engineering research data, as it allows replica-
tion of this study on the same or different populations.
The GitHub community is large (30 million visitors per
month (Doll, 2015)) and diverse in terms terms of team
size, type of software, and several other characteristics.
Our sample is similarly diverse and is balanced in terms
of demographic characteristics, including participant role,
age, experience, work type, company size, and students
versus workers. One exception is gender: our sample is
strongly biased towards males. The direction of the bias
13

may be the same as in the general population. Unfortu-
nately, it is a known problem that software engineering
roles are predominantly filled by males (Ortu et al., 2016;
Terrell et al., 2016; Ford et al., 2016), although recent re-
search is attempting to tackle the issue. Data from some
sources indicate between 7.6%6and 20%7females, with
numbers possibly depending on the definition of developer
and the countries or cultures represented.
5.3. Recommendations for Practitioners
We believe that our discovered consequences of happi-
ness and unhappiness of developers should be of interest to
practitioners working as managers, team leaders, but also
team members and solo software developers. To facilitate
such use, we have made the category schemes available as
archived open data (Graziotin et al., 2017c). Practitioners
in leadership positions should attempt to foster overall hap-
piness of software development teams by limiting their un-
happiness and promoting factors that contribute to happy
experiential episodes. The benefits of fostering happiness
among developers were empirically demonstrated in past
research, and they especially highlight software develop-
ment productivity and software quality boosts. With our
results, we add that addressing unhappiness will limit the
damage in terms of several factors at the individual, arte-
fact, and process level. We also add that addressing hap-
piness can impact the very core prerequisites for software
development: cognitive performance, motivation, and a
positive atmosphere at the workplace. We note that pre-
vious research (Graziotin et al., 2015a) has suggested that
intervening on the affect of developers might have rela-
tively low costs and astonishing benefits.
5.4. Implications for Researchers
We believe that the results of the present work could
be adopted as the basis of several research directions. Our
study has the potential to open up new avenues in soft-
ware engineering research based on the discovered factors
(e.g., work withdrawal and affect of developers). Also, all
the factors we have reported are the end part of an expe-
rienced causality chain with unhappiness or happiness as
the antecedent. Future studies should attempt to seek a
quantification of the chain.
We found that broadly speaking, developers more fre-
quently consider their happiness to benefit themselves, and
their unhappiness to be detrimental to others. The lat-
ter part of this observation was weaker than the former.
Future research could attempt to uncover whether this
finding holds in other samples of the software developer
population, and, if so, investigate whether this is due to a
6StackOverflow Developer Survey 2017,
https://stackoverflow.com/insights/survey/2017
7Bureau of Labor Statistics Current Population Survey: Annual
averages, Software developers, applications and systems software,
https://www.bls.gov/cps/cpsaat11.htm
bias among developers or if there are different underlying
reasons.
Finally, as we have demonstrated, software developers
experience a multitude of consequences arising from hap-
piness and unhappiness. The consequences touch upon
several issues that are of traditional interest in software
engineering research, such as productivity in software pro-
cesses, process adherence, and software quality. Our work
indicates that (un)happiness, and, more generally, affect,
should be taken into account in empirical studies inves-
tigating developers conducting activities related to such
outcomes. This applies on the individual level, but also
on aggregated levels of analysis, such as teams and organ-
isations. We argue that ignoring the factors reported in
this article can lead to incorrect inferences, or, at the very
least, lead to omitting important confounding variables.
Considering them could at best lead to novel insights and
solution proposals for improving the practice of software
engineering, and at least would give a voice to develop-
ers volunteering their time as research subjects. We call
for software engineering researchers to take (un)happiness
into account in their studies.
6. Conclusion
In this paper, we presented the results of an analysis
of the experienced consequences of unhappiness and hap-
piness among software developers while developing soft-
ware. The complete results are archived and available as
open data (Graziotin et al., 2017c). The consequences are
grouped into the main categories of internal – developer’s
own being – and external – process and artefact. The
highest impact of both happiness and unhappiness is ex-
perienced to be on development productivity and quality
as expressed by cognitive performance, including creativ-
ity and flow, and process-related performance. We found
several instances of job-related adverse effects of unhappi-
ness and even indications of mental disorders: work with-
drawal, stress, anxiety, burnout, and depression4. We also
found instances of effects beneficial to well-being, such
as a perceived positive atmosphere at work, higher self-
accomplishment, work engagement, perseverance, creativ-
ity, and self-confidence. Overall, our results indicate that
developers experience happiness more as benefiting them-
selves, and unhappiness more as being detrimental to oth-
ers.
Our recommendation to practitioners, including man-
agers and team leaders, is to utilize our list of consequences
and the explanations offered by the present paper to start
their quest for enhancing the working conditions of soft-
ware developers. The consequences, in particular, offer
interesting angles which managers should reflect on and
look out for in their workforce.
We believe that our study results are of immediate ap-
plication in future academic work. The results set the-
oretical foundations for causality studies and inspiration
for novel research activities in software engineering. Our
14

own aims for future research include work towards com-
pleting the picture of (un)happiness among software devel-
opers in terms of causes, links between causes and conse-
quences, and separating positive and negative causes and
consequences of both happiness and unhappiness.
The present study enforces the stance that many as-
pects of software engineering research require approaches
from the behavioural and social sciences; we believe there
is a need in future academic discussions to reflect on how
software engineering research can be characterized in such
terms. Developers are prone to share work-related horror
stories on a daily basis, and we believe that their job con-
ditions are often overlooked. With our past and present
research activities, we hope we can contribute towards
higher well-being of software engineers, while enhancing
the amount and quality of their job outputs.
Acknowledgements
The authors would like to thank all those who partici-
pated in this study. Daniel Graziotin has been supported
by the Alexander von Humboldt (AvH) Foundation.
References
Baas, M., De Dreu, C.K.W., Nijstad, B.A., 2008. A Meta-Analysis of
25 Years of Mood-Creativity Research: Hedonic Tone, Activation,
or Regulatory Focus? Psychological Bulletin 134, 779–806.
Brooks, F.P., 1975. The Mythical Man-Month. Addison-Wesley.
Colomo-Palacios, R., Casado-Lumbreras, C., 2011. Using the Affect
Grid to Measure Emotions in Software Requirements Engineering.
Journal of Universal Computer Science 17, 1281–1298.
Corbin, J.M., Strauss, A.L., 2008. Basics of Qualitative Research:
Techniques and Procedures for Developing Grounded Theory. vol-
ume 2. 3 ed., Sage Publications, London.
Creswell, J.W., 2009. Research design: qualitative, quantitative, and
mixed method approaches. volume 2. 3 ed., Sage Publications,
Thousand Oaks, California.
Csikszentmihalyi, M., 1997. Finding flow: The psychology of en-
gagement with everyday life. volume 30 of Personnel. 1 ed., Basic
Books, New York, New York, USA.
Curtis, B., Krasner, H., Iscoe, N., 1988. A Field Study of the Soft-
ware Design Process for Large Systems. Communications of the
ACM 31, 1268–1287.
Davis, M.A., 2009. Understanding the relationship between mood
and creativity: A meta-analysis. Organizational Behavior and
Human Decision Processes 108, 25–38.
Denning, P.J., 2012. Moods. Communications of the ACM 55, 33.
Destefanis, G., Ortu, M., Counsell, S., Swift, S., Marchesi, M.,
Tonelli, R., 2016. Software development: do good manners mat-
ter? PeerJ Computer Science 2, e73.
Diener, E., Suh, E.M., Lucas, R.E., Smith, H.L., 1999. Subjective
well-being: Three decades of progress. Psychological Bulletin 125,
276–302.
Diener, E., Wirtz, D., Tov, W., Kim-Prieto, C., Choi, D.w., Oishi, S.,
Biswas-Diener, R., 2010. New Well-being Measures: Short Scales
to Assess Flourishing and Positive and Negative Feelings. Social
Indicators Research 97, 143–156.
Djamba, Y.K., Neuman, W.L., 2002. Social Research Methods: Qual-
itative and Quantitative Approaches. Teaching Sociology 30, 380.
Doll, B., 2015. A closer look at Europe. URL:
https://github.com/blog/2023-a-closer- look-at- europe.
Fagerholm, F., Ikonen, M., Kettunen, P., M¨unch, J., Roto, V., Abra-
hamsson, P., 2015. Performance Alignment Work: How software
developers experience the continuous adaptation of team perfor-
mance in Lean and Agile environments. Information and Software
Technology 64, 132–147.
Fisher, C.D., 2000. Mood and emotions while working: missing
pieces of job satisfaction? Journal of Organizational Behavior 21,
185–202.
Ford, D., Parnin, C., 2015. Exploring causes of frustration for soft-
ware developers, in: Proceedings of the Eighth International Work-
shop on Cooperative and Human Aspects of Software Engineering,
IEEE Press. pp. 115–116.
Ford, D., Smith, J., Guo, P.J., Parnin, C., 2016. Paradise Unplugged:
Identifying Barriers for Female Participation on Stack Overflow,
in: In Proc. 24th ACM SIGSOFT International Symposium on
Foundations of Software Engineering, ACM, New York, NY, USA.
pp. 846–857. doi:10.1145/2950290.2950331.
Fran¸ca, C., Sharp, H., da Silva, F., 2014. Motivated software engi-
neers are engaged and focused, while satisfied ones are happy, in:
Proceedings of the 8th ACM/IEEE International Symposium on
Empirical Software Engineering and Measurement, ACM Press,
New York, New York, USA. pp. 1–8.
Gl¨aser, J., Laudel, G., 2013. Life With and Without Coding: Two
Methods for Early-Stage Data Analysis in Qualitative Research
Aiming at Causal Explanations. Forum: Qualitative Social Re-
search .
Gousios, G., Storey, M.a., Bacchelli, A., 2016. Work practices and
challenges in pull-based development, in: Proc. 38th International
Conference on Software Engineering - ICSE ’16, pp. 285–296.
Graziotin, D., Fagerholm, F., Wang, X., Abrahamsson, P., 2017a.
Consequences of Unhappiness While Developing Software, in: Pro-
ceedings of the 2nd International Workshop on Emotion Aware-
ness in Software Engineering, IEEE Press, Piscataway, NJ, USA.
pp. 42–47.
Graziotin, D., Fagerholm, F., Wang, X., Abrahamsson, P., 2017b.
On the Unhappiness of Software Developers, in: Proceedings of
the 21st International Conference on Evaluation and Assessment
in Software Engineering, ACM, New York, NY, USA. pp. 324–333.
Graziotin, D., Fagerholm, F., Wang, X., Abrahamsson, P., 2017c.
Online appendix: the happiness of software developers. figshare
Https://doi.org/10.6084/m9.figshare.c.3355707.
Graziotin, D., Fagerholm, F., Wang, X., Abrahamsson, P., 2017d.
Unhappy Developers: Bad for Themselves, Bad for Process, and
Bad for Software Product, in: Proc. 2017 IEEE/ACM 39th Inter-
national Conference on Software Engineering Companion (ICSE-
C), ACM.
Graziotin, D., Wang, X., Abrahamsson, P., 2014a. Do feelings mat-
ter? On the correlation of affects and the self-assessed productiv-
ity in software engineering. Journal of Software: Evolution and
Process 27, 467–487.
Graziotin, D., Wang, X., Abrahamsson, P., 2014b. Happy software
developers solve problems better: psychological measurements in
empirical software engineering. PeerJ 2, e289.
Graziotin, D., Wang, X., Abrahamsson, P., 2014c. Software Devel-
opers, Moods, Emotions, and Performance. IEEE Software 31,
24–27.
Graziotin, D., Wang, X., Abrahamsson, P., 2015a. How do you feel,
developer? An explanatory theory of the impact of affects on
programming performance. PeerJ Computer Science 1, e18.
Graziotin, D., Wang, X., Abrahamsson, P., 2015b. The Affect of Soft-
ware Developers: Common Misconceptions and Measurements.
Proceedings of the Eighth International Workshop on Coopera-
tive and Human Aspects of Software Engineering , 123–124.
Graziotin, D., Wang, X., Abrahamsson, P., 2015c. Understanding
the affect of developers: theoretical background and guidelines for
psychoempirical software engineering, in: SSE 2015: Proceedings
of the 7th International Workshop on Social Software Engineering,
ACM. pp. 25–32.
Grigorik, I., 2012. GitHub Archive. URL:
https://githubarchive.org.
Haybron, D.M., 2001. Happiness and Pleasure. Philosophy and
Phenomenological Research 62, 501–528.
Haybron, D.M., 2005. On Being Happy or Unhappy. Philosophy and
15

Phenomenological Research 71, 287–317.
Kahneman, D., 1999. Objective Happiness, in: Kahneman, D., Di-
ener, E., Schwarz, N. (Eds.), Well-Being: Foundations of Hedonic
Psychology. Utilitas, New York, NY, USA, pp. 3–25.
Khan, I.A., Brinkman, W.P., Hierons, R.M., 2010. Do moods af-
fect programmers’ debug performance? Cognition, Technology &
Work 13, 245–258.
Lenberg, P., Feldt, R., Wallgren, L.G., 2015. Behavioral software
engineering. Journal of Systems and Software 107, 15–37.
Lyubomirsky, S., King, L., Diener, E., 2005. The benefits of frequent
positive affect: does happiness lead to success? Psychological
bulletin 131, 803–855.
M¨antyl¨a, M., Adams, B., Destefanis, G., Graziotin, D., Ortu, M.,
2016. Mining valence, arousal, and dominance: possibilities for
detecting burnout and productivity?, in: MSR ’16: Proceedings
of the 13th International Conference on Mining Software Reposi-
tories, Brunel University. ACM, New York, New York, USA. pp.
247–258.
Miner, A.G., Glomb, T.M., 2010. State mood, task performance,
and behavior at work: A within-persons approach. Organizational
Behavior and Human Decision Processes 112, 43–57.
Mitchell, T.R., 1982. Motivation: New Directions for Theory, Re-
search, and Practice. The Academy of Management Review 7,
80–88.
M¨uller, S.C., Fritz, T., 2015. Stuck and Frustrated or in Flow and
Happy: Sensing Developers’ Emotions and Progress, in: Proc.
37th IEEE International Conference on Software Engineering,
IEEE. pp. 688–699.
Novielli, N., Calefato, F., Lanubile, F., 2015. The challenges of senti-
ment detection in the social programmer ecosystem, in: SSE 2015
Proceedings of the 7th International Workshop on Social Software
Engineering, ACM, New York, New York, USA.
Ortu, M., Adams, B., Destefanis, G., Tourani, P., Marchesi, M.,
Tonelli, R., 2015. Are Bullies More Productive? Empirical Study
of Affectiveness vs. Issue Fixing Time, in: 2015 IEEE/ACM
12th Working Conference on Mining Software Repositories (MSR),
IEEE. pp. 303–313.
Ortu, M., Destefanis, G., Counsell, S., Swift, S., Marchesi, M.,
Tonelli, R., 2016. How diverse is your team? Investigating gen-
der and nationality diversity in GitHub teams. Peerj Preprints ,
e2285v1.
Russell, J.A., 2003. Core affect and the psychological construction
of emotion. Psychological review 110, 145–172.
Stol, K.J., Ralph, P., Fitzgerald, B., 2016. Grounded Theory in
Software Engineering Research: A Critical Review and Guide-
lines, in: Proceedings of the 38th International Conference on
Software Engineering, ACM, New York, NY, USA. pp. 120–131.
doi:10.1145/2884781.2884833.
Terrell, J., Kofink, A., Middleton, J., Rainear, C., Murphy-Hill, E.,
Parnin, C., Stallings, J., 2016. Gender differences and bias in
open source: Pull request acceptance of women versus men. Peerj
Preprints , e1733v2.
Vecchio, R.P., 2000. Negative Emotion in the Workplace: Employee
Jealousy and Envy. International Journal of Stress Management
7, 161–179.
Wrobel, M.R., 2013. Emotions in the software development process.
2013 6th International Conference on Human System Interactions
(HSI) , 518–523.
Zelenski, J.M., Murphy, S.A., Jenkins, D.A., 2008. The Happy-
Productive Worker Thesis Revisited. Journal of Happiness Studies
9, 521–537.
16