Conference PaperPDF Available

On the Unhappiness of Software Developers


Abstract and Figures

The happy-productive worker thesis states that happy workers are more productive. Recent research in software engineering supports the thesis, and the ideal of flourishing happiness among software developers is often expressed among industry practitioners. However, the literature suggests that a cost-effective way to foster happiness and productivity among workers could be to limit unhappiness. Psychological disorders such as job burnout and anxiety could also be reduced by limiting the negative experiences of software developers. Simultaneously, a baseline assessment of (un)happiness and knowledge about how developers experience it are missing. In this paper, we broaden the understanding of unhappiness among software developers in terms of (1) the software developer population distribution of (un)happiness, and (2) the causes of unhappiness while developing software. We conducted a large-scale quantitative and qualitative survey, incorporating a psychometrically validated instrument for measuring (un)happiness, with 2,220 developers, yielding a rich and balanced sample of 1,318 complete responses. Our results indicate that software developers are a slightly happy population, but the need for limiting the unhappiness of developers remains. We also identified 219 factors representing causes of unhappiness while developing software. Our results, which are available as open data, can act as guidelines for practitioners in management positions and developers in general for fostering happiness on the job. We suggest future research in software engineering should consider happiness in studies of human aspects and even in seemingly unrelated technical areas.
Content may be subject to copyright.
On the Unhappiness of Soware Developers
Daniel Graziotin
Institute of Software Technology
University of Stuttgart
Stuttgart, Germany
Fabian Fagerholm
Department of Computer Science
University of Helsinki
Helsinki, Finland
Xiaofeng Wang
Faculty of Computer Science
Free University of Bozen-Bolzano
Bolzano-Bozen, Italy
Pekka Abrahamsson
Department of Computer and Information Science (IDI)
Trondheim, Norway
The happy-productive worker thesis states that happy workers are
more productive. Recent research in software engineering supports
the thesis, and the ideal of ourishing happiness among software de-
velopers is often expressed among industry practitioners. However,
the literature suggests that a cost-eective way to foster happiness
and productivity among workers could be to limit unhappiness.
Psychological disorders such as job burnout and anxiety could also
be reduced by limiting the negative experiences of software devel-
opers. Simultaneously, a baseline assessment of (un)happiness and
knowledge about how developers experience it are missing. In this
paper, we broaden the understanding of unhappiness among soft-
ware developers in terms of (1) the software developer population
distribution of (un)happiness, and (2) the causes of unhappiness
while developing software. We conducted a large-scale quantitative
and qualitative survey, incorporating a psychometrically validated
instrument for measuring (un)happiness, with 2 220 developers,
yielding a rich and balanced sample of 1 318 complete responses.
Our results indicate that software developers are a slightly happy
population, but the need for limiting the unhappiness of develop-
ers remains. We also identied 219 factors representing causes of
unhappiness while developing software. Our results, which are
available as open data, can act as guidelines for practitioners in man-
agement positions and developers in general for fostering happiness
on the job. We suggest future research in software engineering
should consider happiness in studies of human aspects and even in
seemingly unrelated technical areas.
Social and professional topics Project and people man-
agement; Applied computing Psychology; Software and
its engineering
Software creation and management; Program-
ming teams;
Permission to make digital or hard copies of part or all of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for prot or commercial advantage and that copies bear this notice and the full citation
on the rst page. Copyrights for third-party components of this work must be honored.
For all other uses, contact the owner/author(s).
EASE ’17, BTH, Sweden
©2017 Copyright held by the owner/author(s). 123-4567-24-567/08/06.. .$15.00
DOI: 10.475/123_4
behavioral software engineering; developer experience; human
aspects; aect; emotion; mood; happiness
ACM Reference format:
Daniel Graziotin, Fabian Fagerholm, Xiaofeng Wang, and Pekka Abrahams-
son. 2017. On the Unhappiness of Software Developers. In Proceedings
of 21st International Conference on Evaluation and Assessment in Software
Engineering, BTH, Sweden, June 15–16 2017 (EASE ’17), 10 pages.
DOI: 10.475/123_4
The need and importance of managing the individuals forming
the software development workforce were identied early in soft-
ware engineering research [
]. Management and people related
challenges grow as the numbers of software companies and devel-
opers increase with the digitalization of existing businesses and
startups founded on software from day one [
]. A practice that
has emerged recently is to promote ourishing happiness among
workers in order to enact the happy-productive worker thesis [
Notable Silicon Valley companies and inuential startups are well
known for their perks to developers [
]. Recognizing the happi-
ness of all stakeholders involved in producing software is essential
to software company success [10].
A novel line of research belonging to behavioral software engi-
neering [
] is emerging, focusing on the relationship between the
happiness of developers and work-related constructs such as per-
formance and productivity [
], and software
quality [
]. The empirical evidence indicates that happy devel-
opers perform better than unhappy developers [
]. The studies so
far, including those by the present authors, imply that managers
and team leaders should attempt to foster developer happiness.
There is the other side of the coin, though. Diener [
] and
Kahneman [
] have suggested that objective happiness
can be
assessed by the dierence between experienced positive aect and
experienced negative aect. The happiness equation suggests that
maximizing happiness can be achieved by maximizing positive
We are using the more colloquial term happiness instead of subjective well-being
throughout the paper as it has historical meaning to research in organizational behavior
and psychology [
]. Furthermore, as our view of unhappiness contemplates it as the
negative component of happiness, we interchange the two terms when dealing with
quantications of developers’ (un)happiness.
EASE ’17, June 15–16 2017, BTH, Sweden Daniel Graziotin, Fabian Fagerholm, Xiaofeng Wang, and Pekka Abrahamsson
experiences of individuals, minimizing their negative experiences,
or both.
Software developers are prone to share horror stories about their
working experience on a daily basis [
]. Those in managerial po-
sitions should attempt to understand the nature and dynamics of
unhappiness in the workplace to create programs for preventing
dysfunctional responses among employees [
]. Psychological dis-
orders such as stress and burnout could be reduced by analyzing
the negative aective experiences of developers and turning them
positive [
]. Furthermore, the voice of practitioners should be
heard in software engineering research – software developers want
their unhappiness to be voiced out [
]. For the previously
stated reasons, there are calls to understand the benets of limiting
negative experiences on the job [3, 12, 24].
The current research on software developers’ aective experi-
ence lacks a baseline estimation of the distribution of happiness
among software developers, as well an understanding of the causes
of unhappiness that would be based on a broad sample.
In this paper, we echo the previous calls and aim to
broaden the understanding of unhappiness among software developers.
Research questions.
Based on the existing literature, we set
the following research questions (RQs).
What is the distribution of (un)happiness among software de-
What are the experienced causes for unhappiness among soft-
ware developers while developing software?
To answer the RQs, we conducted a large-scale quanti-
tative and qualitative survey of 2 220 software developers in which
we asked them to voice out causes of happiness as well as unhappi-
We computed the population estimate of happiness,
found 219 causes of unhappiness, and showed that the most preva-
lent causes of unhappiness are external to developers, suggesting
that managers and team leaders have a realistic chance of inuenc-
ing the happiness of software developers at work. We archived the
list of causes as open data [31].
What is happiness, and what does it mean to be happy or unhappy?
Intuitively, we could associate this question to the sensing of an
individual’s aect. We begin by discussing aect, emotions, and
Russell [
] has provided a widely agreed denition of aect as
a neurophysiological state that is consciously accessible as a simple,
non-reective feeling that is an integral blend of hedonic (pleasure–
displeasure) and arousal (sleepy–activated) values” (p. 147). That is,
aect is how we feel at any given point in time, about anything,
and this feeling is expressed in how pleasant and activated our state
of mind is. We have argued elsewhere [
] that there are several
theories and denitions for emotions and moods. For clarity and
brevity, we use Russell’s [
] theory for the present paper, which
considers aect as the atomic unit upon which moods and emotions
can be constructed. We consider moods as prolonged, unattributed
aect, and we consider emotions as interrelated events concerning a
psychological object, i.e., an episodic process of perception of aect
that is clearly bounded in time, in line with several other authors,
e.g., [21, 44].
From a hedonistic point of view, a blend of aect constitutes an
individual’s happiness [
]. Happiness is a sequence of experiential
episodes [
] and being happy (unhappy) corresponds with the fre-
quency of positive (negative) experiences [50]2. Frequent positive
(negative) episodes lead to feeling frequent positive (negative) aect,
which in turn leads to happiness (unhappiness), represented by a
positive (negative) aect balance [
]. In brief, unhappy individuals
are those who experience negative aect more often than positive
aect, which is a condition that can be detected by a negative aect
balance [13, 50].
2.1 Scale of Positive and Negative Experience
Recent studies have found several shortcomings in the Positive and
Negative Aect Schedule (PANAS) [
], the most prominent mea-
surement instrument for assessing happiness, in terms of its aect
coverage [
] and neglect of cultural dierences [
New scales have been developed that attempt to address PANAS’
limitations. Diener et al. [
] have presented the Scale of Positive
and Negative Experience (SPANE), a short scale that assesses the
happiness of participants by asking them to report the frequency of
their positive and negative experiences during the last four weeks.
SPANE has been reported to be capable of measuring positive and
negative aect (and happiness) regardless of the sources, mental
activation level, or cultural context, and it captures aect from the
entire aective spectrum [
]. Respondents are asked to report
on their aect, expressed with adjectives that individuals recognize
as describing emotions or moods, from the past four weeks in order
to provide a balance between the sampling adequacy of aect and
the accuracy of human memory to recall experiences [49], as well
as to decrease the ambiguity of people’s understanding of the scale
itself [13].
SPANE has been validated to converge to other similar mea-
surement instruments, including PANAS [
]. The scale provides
good psychometric properties (validity and reliability) which were
empirically demonstrated in several large-scale studies [
]. The scale has been proven consistent across full-time
workers and students [
]. For these reasons (and for its brevity),
we chose SPANE for the purpose of our research.
SPANE is a 12-item scale divided into two sub-scales of positive
(SPANE-P) and negative (SPANE-N) experiences. The answers to
the 12 items are given on a ve-point scale ranging from 1 (very
rarely or never) to 5 (very often or always). The SPANE-P and SPANE-
N measures are the sum of the scores given to their respective
six items, each ranging from 6 to 30. The two scores are further
combined by subtracting SPANE-N from SPANE-P, resulting in the
Aect Balance (SPANE-B) score. SPANE-B is an indicator of the
happiness caused by how often positive and negative aect has
been felt by a participant. SPANE-B ranges from
24 (completely
negative) to +24 (completely positive).
There are alternative views of happiness, such as the Aristotelian eudaimonia, which
considers a person happy because (s)he conducts a satisfactory life full of quality [
We have also discussed the role of the centrality of aect in [
]. While these issues
are important to understand, they do not aect the present study.
On the Unhappiness of Soware Developers EASE ’17, June 15–16 2017, BTH, Sweden
2.2 Related Studies
Interest in studying the aect of software developers has risen
considerably in the last ve years, although we have just started
to understand the tip of the iceberg [
]. To our knowledge, no
studies have oered an estimation of the happiness distribution of
developers, and only a small number of causes of developers’ aect
have been examined in a few studies. The present study addresses
this research gap.
There are some initial indicators regarding developers’ happiness.
Generally speaking, studies indicate a positive relationship between
the happiness of developers and their performance. Graziotin et
al. [
] performed a quasi-experiment on the impact of aect on
analytic problem solving and creative performance. The study itself
was about consequences of happiness, thus not particularly related
to the present article. Yet, Graziotin et al. observed that the sample
distribution of happiness, measured using SPANE, was signicantly
greater than 0 (SPANE-B mean=7
58, 95% CI [5.29, 9.85]; median=9).
The authors noted that the SPANE-B distribution did not resemble
a normal distribution. However, the sample was very limited (N=42
BSc and MSc students of the same CS faculty); further exploration
and validation were suggested based on the observations. We build
on these initial observations in the present study.
Some studies have attempted to uncover issues related to aect
using both qualitative and quantitative approaches with dierent de-
grees of automation. De Choudhury and Counts [
] investigated the
expression of aect through the analysis of 204 000 micro-blogging
posts from 22 000 unique users of a Fortune 500 software corpora-
tion. The sentiment analysis revealed that IT-related issues were
often sources of frustration. Day-to-day demands, e.g., meetings,
were also associated with negative aect.
Ford and Parnin [
] have explored frustration in software engi-
neering through practitioner interviews. 67% of the 45 participants
reported that frustration is a severe issue for them. As for the
causes for such frustration, the authors categorized the responses
as follows: not having a good mental model of the code (for the
category “mapping behavior to cause”), learning curves of program-
ming tools, too large task size, time required for adjusting to new
projects, unavailability of resources (e.g., documentation, server
availability, .. . ), perceived lack of programming experience, not
fullling the estimated eort for perceived simple problems, fear
of failure, internal hurdles and personal issues, limited time, and
issues with peers.
Graziotin et al. [
] conducted a qualitative study for construct-
ing an explanatory process theory of the impact of aect on devel-
opment performance. The theory was constructed by coding data
coming from interviews, communications, and observations of two
software developers working on the same project for a period of 1.5
months. The theory was built upon the concepts of events, aect,
focus, goals, and performance. The study theorized the construct
of attractors, which are aective experiences that earn importance
and priority to a developer’s cognitive system. Attractors were
theorized to have the biggest impact on development performance.
Finally, the study suggested that interventions (e.g., facilitating
reconciliation between developers who are angrily arguing) can
mediate the intensity of existing negative aect and reduce their
intensity and disruption.
Wrobel [
] conducted a survey with 49 developers, assessing the
participants’ emotions that were perceived to be those inuencing
their productivity. The results showed that positive aective states
were perceived to be those enhancing development productivity.
Frustration was perceived as the most prevalent negative aect, as
well as the one mostly deteriorating productivity.
Ortu et al. [
], Destefanis et al. [
], and Mäntylä et al. [
conducted a series of mining software repositories studies to under-
stand how aect, emotions, and politeness are related to software
quality issues. The studies showed that happiness in terms of fre-
quent positive aect and positive emotions was associated with
shorter issue xing time. Issue priority was found to be associated
with the arousal mental activation level, which is often associated
with anxiety and burnout.
We employed a mixed research method, comprising both elements
of quantitative and qualitative research [
]. In particular, we opted
to approach RQ1 with a quantitative investigation, while we ad-
dressed RQ2 with a mostly qualitative inquiry. As our aim was to
learn from a large number of individuals belonging to a particu-
lar population, we considered a survey, implemented as an online
questionnaire, to be the most appropriate instrument [17].
3.1 Sampling Strategy
We consider a software developer to be a person concerned with
any aspect of the software construction process (such as research,
analysis, design, programming, testing, or management activities),
for any purpose including work, study, hobby, or passion. Gen-
eralizing to the population of software developers is a challenge,
because we do not accurately know how many software develop-
ers exist in the world and how to reach them. We relied on the
GitHub social coding community as a source that ts our purpose
of generalization well enough, in line with several previous studies
(e.g., [
]). GitHub is the largest social coding community with
more than 30 million visitors each month [
], many of which
are software developers working on open source and proprietary
software ranging from solo work to companies and communities.
To obtain the contact information of GitHub developers, we
retrieved related data through the GitHub Archive [
], which
stores the collections of public events occurring in GitHub. In
order to ensure a sample of high quality and variety, we obtained
six months of archive data, from March 1 to September 30, 2014.
We extracted unique entries that provided an e-mail address. We
gathered 456 283 entries of contact data, which included email
address, given name, company, and location of the developers, and
the repository name related to the public activity. 41.7% of the data
provided an entry for the company eld.
3.2 Survey Design
We collected data and enhanced the survey in four rounds. During
the rst three rounds, we piloted the questionnaire design with a
limited random sample of contact data (N=100 in each round). We
discarded the pilots’ contact data and questionnaire data from the
nal survey as many guidelines recommend (e.g., [48]).
EASE ’17, June 15–16 2017, BTH, Sweden Daniel Graziotin, Fabian Fagerholm, Xiaofeng Wang, and Pekka Abrahamsson
The three pilot rounds allowed us to estimate and improve the
participation and response rate of the study through a renement
of the questions and invitation e-mail. Through the pilot tests, we
understood that we could expect a high percentage of delivered
e-mails (between 97% and 98%) and that we could expect a low
participation rate (between 2% and 4%). The participation rate
increased in each run.
The questionnaire used in the nal survey is composed of (1)
questions to collect demographic information, (2) one question
carrying SPANE’s 12 scale items, and (3) two open-ended questions
on the causes of happiness and unhappiness (in terms of SPANE-
P and SPANE-N components, see Section 2.1) while developing
software. The questionnaire also provides an open-ended eld
for further comments and a eld for optionally leaving an e-mail
address for possible follow-ups
. The questionnaire is available in
an archived online appendix [31].
For estimating the sample size required to make inferences re-
garding our population of developers, we evaluated the sample size
estimations by Bartlett et al. [
], Krejcie & Morgan [
], Cochran [
and Yamane [
], for a-priori statistical power. None of the authors
have proposed sample size estimations for open-ended, qualitative
entries. Therefore, we decided to opt for the most conservative set-
tings, i.e., Yamane’s simplied formula [
] with
01 assuming
a 2% response rate. Our calculations resulted in a desirable sample
of N=664 complete responses, which we expected to reach with
33 200 requests under a 2% response rate.
We designed and published the questionnaire with eSurvey Cre-
ator and invited the participants via e-mail. We did not share the
survey elsewhere.
3.3 Analysis and Data Cleaning
In order to answer RQ1, we needed to describe the distribution
of the SPANE-B happiness score (see Section 2.1) and to provide
an estimation for the population mean and median. We expected
to employ non-parametric methods for the mean and median esti-
mation, given our earlier study [
] and the information obtained
from the three pilot runs.
In order to answer RQ2, we developed a coding strategy for
the open-ended questions. We applied open coding, axial coding,
and selective coding, as described by Corbin and Strauss [
], as
follows. The rst three authors individually open coded the same
set of 50 random responses using a line-by-line strategy. We met
through online video calls in order to compare the coding structure
and strategy to reach an agreement, that is, a shared axial coding
mechanism. Our unit of observation and analysis, the individual
developer, was the starting point. We framed our construction
of theoretical categories based on Curtis et al. [
] model of con-
structs that are internal or external, with the internal group being
the developer’s own being and the external group having the ar-
tifact, process, and people as subcategories. Then, we divided the
responses and proceeded to open code them (each coder coded a
third of the answers). We held a weekly meeting to follow progress
and further discuss the coding structure and strategy. Finally, we
merged the codes and performed a nal selective coding round. We
We designed the invitation e-mail and questionnaire text ensuring informed consent
by the participants.
used NVIVO 11 for the entire qualitative task. We provide a working
example of the various coding phases in the online appendix [31].
Data cleaning happened during all stages of the study. We
adopted common data cleaning strategies, such outlier analysis
(for example, we examined birth years after 2000 and excluded two
1-year old participants), and excluding participants who were not
in the intended population or put random text in the text elds.
We list the data inclusion and exclusion criteria in the archived
online appendix [
]. We used R [
] scripts for supporting and
automating the data cleaning, data exploration, and data analysis
This section details the results of our investigation. We rst provide
descriptive statistics on the sample demographics. Then, we provide
the results related to each research question.
4.1 Descriptive Statistics
Following our conservative strategy, we randomly sampled 33 200
entries from our contact list. Our sending tool delivered 31 643
(96.6%) invitation e-mails; the remaining addresses were either
malformed or bounced. 2 220 individuals participated (7% response
rate). 1 908 participants provided valid data for answering RQ1
(86%) while 1 318 provided valid data to provide answers to RQ2
(59%). Based on the pilots, we anticipated that some participants
would leave the open-ended questions unanswered. Our sampling
strategy paid o: we exceeded the required threshold (N=664) for
generalizing. The rich sample oered us the opportunity to stay
conservative for analyzing the data, too. We could minimize bias by
retaining only the data provided by the participants that completed
the entire questionnaire. That is, we kept N=1318 for answering all
our RQs.
Our sample of N=1318 responses resulted in 1 234 male partic-
ipants (94%) and 65 female (5%). The remaining 19 participants
declared their gender as other / prefer not to disclose. The average
year of birth was 1984 (standard deviation (sd)=9.33), while the
mean was 1986. There was diversity in terms of nationality, with
88 countries. The most represented nationalities were American
(24%), Indian (6%), Brazilian (6%), Russian (5%), and British (4%).
A total of 993 (75%) of the participants were professional software
developers, 15% of the sample were students, and 8% were in other
roles (such as manager, CEO, CTO, and academic researcher). The
remaining participants were non-employed and not students.
The participants declared an average of 8.29 years (sd=7.77) of ex-
perience with working with software development, with a median
of 5 years. 240 participants developed software either as a hobby,
passion, or volunteer without pay, 161 participants worked either
as freelancer or consultant in companies, 105 participants were a
one-person company or self-employed in a startup, and 812 were
employed in a company or a public organization. The reported size
of the participants’ company or organization also varied consider-
ably, with 13.3% of the participants working alone, 33.6% in small
entities (2-10 persons), 34.4% in medium entities (11-250), and 18.7%
in large to very large entities (250-5000 and more).
Regarding the qualitative data, we reached a total of 590 codes in
the initial coding phases. After the merge and cleanup phases, we
On the Unhappiness of Soware Developers EASE ’17, June 15–16 2017, BTH, Sweden
Figure 1: Happiness of software developers (SPANE-B distri-
obtained 219 codes that were referenced 2 280 times in text (average
of 10.41 references per code).
4.2 RQ1—What is the Distribution of (Un)
Happiness Among Software Developers?
Our sample of N=1318 participants had a SPANE-B (see Section 2.1)
mean score of 9.05 (sd=6.76), a median score of 10, and a range of
[-16, 24].
We followed the recent suggestion by Kitchenham et al. [
] to
use kernel density plot instead of boxplots. The plot of the SPANE-B
score is shown in Figure 1. The plot indicates a likely non-normal
distribution of the data, as expected. A description of the SPANE-
B score by the psych R package [
] showed a skew of -0.53 and
a kurtosis of 0.46, indicating a slightly asymmetrical distribution
with a long tail to the left that is atter than a standard normal
distribution. Strong evidence for non-normality of the data was
supported by a Shapiro-Wilk test for normality (
We estimated the population’s true mean for SPANE-B via boot-
strapping as 9
05 (2000 replications, 95% CI [8.69, 9.43]). We esti-
mated the population’s true median for SPANE-B via bootstrapping
as 10 (2000 replications, 95% CI [9.51, 10.71]). We show in the on-
line appendix [
] that estimating those values with the expanded
sample of N=1908 would yield similar results.
4.3 RQ2—What are the Experienced Causes for
Unhappiness Among Software Developers
While Developing Software?
We plotted the demographic data gathered from the questionnaire,
and compared it with the SPANE-B value. None of the quantitative
data plots indicated a relationship with the happiness of developers.
This includes variables such as gender, age, nationality, working
status, company size, percentage of working time dedicated to
developing software, and monthly income. Thus, we conclude that
they are not the primary determinants of unhappiness. This further
conrmed our original research design to use qualitative data to
explore the causes. We identied 219 causes of unhappiness, which
are grouped into 18 categories and sub-categories (including the
Table 1: Categories for External Causes of Unhappiness
Main category Sub-categories
People (416)
colleague (206)
manager (122)
customer (49)
Artifact and
working with artifact
code and coding (217)
bug and bug xing (194)
technical infrastructure (151)
requirements (99)
factors (544) No sub-categories
Other causes (95) No sub-categories
top category of causes of unhappiness while developing software).
We report here only the main emerged categories and top 10 factors.
Because of space limitations, we provide the demographic data plots
and our complete coding as open data in the online appendix [
4.3.1 Main Categories. The main types of factors causing un-
happiness among software developers are organized under two
main categories. The causes of unhappiness internal to individual
developers, directly related to their personal states, or originated
by their own behaviors, are classied under the developer’s own
being category. These occurred a total of 437 times. In contrast,
external causes are the causes of unhappiness external to individual
developers, by which developers are aected but have little or no
control of. The total occurrence of external causes is 1 843 times.
This indicates that developers are much more prone to experiencing
and recalling externally-provoked unhappy feelings than internally
generated ones.
developer’s own being
(i.e., internal causes) category con-
tains 22 internal factors. These factors do not demonstrate a clear
structure. This to some extent reects the versatile states of mind
of developers and the feelings they could have while they develop
The factors in the
external causes
category are further divided
into the sub-categories shown in Table 1. People-related factors: the
external causes of unhappiness related or attributable to people
whom developers interact with, to their characteristics or behaviors.
These occurred 416 times and are further divided based on the roles
of the people. Artifact and working with artifact: the external causes
of unhappiness related to artifacts in software development projects
and developers’ interactions with them occurred 788 times. The
causes are further grouped based on the types of artifacts that devel-
opers are dealing with. Process-related factors: the external causes
of unhappiness related to issues in the management of software
development process and day-to-day work. This type of causes oc-
curred 544 times. Other causes: the external causes of unhappiness
not classied under any of the above-mentioned “external factors”
categories. These non-specic causes occurred 95 times.
4.3.2 10 Most Significant Causes of Unhappiness. We extracted
a list of 10 factors that occurred most often in the survey responses
as the causes of unhappiness. They are listed in Table 2.
EASE ’17, June 15–16 2017, BTH, Sweden Daniel Graziotin, Fabian Fagerholm, Xiaofeng Wang, and Pekka Abrahamsson
Table 2: Top 10 Causes of Unhappiness, Categories, and Frequency
Cause Category Freq.
Being stuck in problem solving software developer’s own being 186
Time pressure external causes process 152
Bad code quality and coding practice external causes artifact and working with artifact code and coding 107
Under-performing colleague external causes people colleague 71
Feel inadequate with work software developer’s own being 63
Mundane or repetitive task external causes process 60
Unexplained broken code external causes artifact and working with artifact code and coding 57
Bad decision making external causes process 42
Imposed limitation on development external causes artifact and working with artifact technical infrastructure 40
Personal issues – not work related software developer’s own being 39
Three of these top 10 causes are part of software developer’s
own being.
Being stuck in problem solving
is by far the most
signicant among the three factors. Software development is essen-
tially composed of problem-solving activities, often intellectually
demanding. It is common that developers may be stuck in cod-
ing, debugging and all sorts of other tasks. As one respondent
commented: “I feel negative when I get really stuck on something
and cannot get around it”. Another respondent elaborated: I also
thought of situations where I’m debugging some issue with the code
and I can’t gure out why it isn’t working – when it seems like ev-
erything should work, but it just doesn’t. This is denitely one of the
biggest gumption traps I encounter”.
Another signicant internal cause is a
feeling of inadequate
skills or knowledge
, as shown in this response: “Once I encoun-
tered hashmap, and I couldn’t understand it while I knew it is im-
portant. I felt frustrated and afraid”. The inadequate feeling can be
manifested as feeling unskilled in certain aspects of the work, feel-
ing under-qualied with respect to the task given, or feeling a lack
of familiarity with tools, languages, frameworks, or development
methods that are used in the projects.
The third signicant cause related to developer’s own being is
not related to work, but
personal issues
. Software developers are
not living in vacuum while working on their software projects, and
often non-work related, personal or private issues may aect them
and cause their unhappy feelings during work. “I never feel 100%
productive when there’s something from my private life bugging me.
No, I’m not a robot, I’m human, and can’t forget the rest of the world
when I start IntelliJ up”. Among the non-work related issues, family
related issues are most frequently mentioned: “Family related issues
has huge impact on my feeling while working, I feel down and can’t
achieve the goals I set for my work day”.
The seven remaining most signicant factors are all external.
Among people-related causes, the
under-performance of col-
, either team members, colleagues in other teams, or exter-
nal collaborators, most often make developers experience negative
feelings and aect their work consequently. An illustrative episode
is reported in this response: “Last time I felt angry when a senior
developer again committed an update ruining a beautiful generic
solution I’ve made before. It was easy to refactor it, but his ignorance
or routine annoyed me”. Software development is often teamwork. It
is frequently frustrating to a developer to see that other colleagues
do not spend time to keep up to speed with modern development
technology and practices.
It comes as no surprise that
bad code quality and coding prac-
make developers unhappy. In almost all cases, bad code
was a cause of unhappiness if it was written by other develop-
ers: “Sad/angry when reading others’ code that I have to use and I
realize it is full of bugs”; “having encountered a particularly bad (un-
readable, poorly formatted, not commented at all, badly structured)
piece of code written by another developer that I had to work on”. Only
a few participants reported unhappiness caused by “poorly written
code (often by past-me)”. That is, unhappiness from code written by
the participants themselves was raised only when regretting past
Another signicant factor related to code that makes developers
feel bad is when they could not explain why the code is not work-
ing as it is supposed to (
unexplained broken code
): “When you
haven’t changed the code, and suddenly the project doesn’t compile
anymore. Worst feeling ever. (Afraid/sad/angry)”.
Apart from code, issues in the technical infrastructure a software
project relies on often contribute to negative feelings among de-
velopers, especially when it is supposed to support software devel-
opment, but instead imposes constraints or limitations (
limitation on development
). One respondent described this sit-
uation perfectly: “Angry happens quite often because tools, program-
ming languages, etc. don’t do as expected. Sometimes because they are
buggy, sometimes there are some limitations in them (by design/by
ignoring or not considering enough use cases, etc.), which makes one
need to nd work-arounds/mess-up otherwise clean code, repeat code
unnecessarily etc”.
Regarding the top signicant causes related to general software
development process, the respondents consider that high
time pres-
they feel, often generated by “unrealistic”, “unjustied” and
crazy” deadlines, will almost surely push them into very unhappy
states. A respondent described vividly this situation: I remembered
a day. I have a lot of phone call from my boss to done a project. in
that situation time was running and project move slowly and phone
every a minute ringed”.
Contrasting the image of high time pressure, with hectic rushing
towards deadlines, is working on
mundane or repetitive tasks
which is another process-related factor that often causes negative
feelings of developers. Tedious”, “boring”, “dull”, “monotonous”,
trivial”, “recurrent”, etc., are the words the respondents used to
On the Unhappiness of Soware Developers EASE ’17, June 15–16 2017, BTH, Sweden
describe the tasks that make them unhappy. “I tend to feel negative
or bad when I am doing something that is not challenging, I instantly
feel sleepy and bored”, a respondent stated.
Bad decision making
is yet another process-related factor that
often leaves developers in an unhappy state. More than bad busi-
ness decisions, developers are more often aected (emotionally as
well) by bad technical decisions made by their superiors or peers.
One example depicts such a scenario: “Generally negative emotions
stem from board meetings where an executive or coworker makes
an uninformed or ill-advised decision that causes a ‘dirty’ codebase
change”. Bad decision making is also perceived by developers if
they are not involved in decision making processes.
Through our analysis to answer RQ1 (Section 4.2), we estimated the
population mean SPANE-B score to be 9
05, indicating a happiness
balance on the positive side (see Section 2.1). In terms of the norms
reported in Diener et al. [
], this result is in the 65th percentile,
indicating that the happiness balance is also higher than what could
be expected in a larger human population. The various psycho-
metric studies of SPANE report sample means but no condence
intervals, meaning that the best comparison possible is through
means and standard deviations. Those studies have found mean
SPANE-B scores above zero, but several score points lower than in
our sample: 7
51 (sd=8
21) in a sample of men and 4
53 (sd=8
in a sample of women in Italy [
]; 6
69 (sd=6
88) in a sample of
college students from ve universities and colleges in USA and
one university in Singapore [
]; 6
66 (sd=8
18) in large sample of
more than 21 000 employees in the Chinese power industry [
96 (sd=6
72) in a multicultural student sample at a large South
African university [
]; 4
41 (sd=7
79) in a sample of full-time em-
ployees and 5
10 (sd=7
54) in a sample of university students, both
in Portugal [
]; and 4
30 (sd=7
50) in a sample of Japanese college
students [64].
Our ndings about the higher-than-expected SPANE-B score
conrm and reinforce our previous observations [
] that (1) soft-
ware developers are a slightly happy population, and that (2) there
is no evidence that the distribution of SPANE-B scores for the
population of software developers should cover the full range of
. This does not mean that software developers are happy
to the point that there is no need to intervene on their unhappi-
ness. On the contrary, we have shown that unhappiness is present,
caused by various factors and some of them could easily be pre-
vented. Our observations and other studies show that unhappiness
has a negative eect both for developers personally and on devel-
opment outcomes. Furthermore, these results have implications for
research, as outlined below.
For answering RQ2, we have shown a wide diversity and weight
of factors that cause unhappiness among developers (Section 4.3).
The causes of unhappiness that are external to developers, and thus
more controllable by managers and team leaders, could have an
incident rate that is 4 times the one of the factors belonging to
the developer’s own being. We expected that the majority of the
causes of unhappiness would come from human related considera-
tions (416 references); however, technical factors from the artifact
(788) and the process (544) dominate the unhappiness of developers,
highlighting the importance of strategic architecture and workforce
coordination. Being stuck in problem solving and time pressure are
the top two most frequent causes of unhappiness, which corrobo-
rates the importance of recent research that attempts to understand
them [
]. Several top causes are related to the perception
of inadequacy of the self and others, which encourages recent re-
search activities on intervening on the aect of developers [
Finally, we see that factors related to information needs in terms of
software quality and software construction are strong contributors
to unhappiness among developers. This reinforces recent research
activities on those aspects(e.g., [
]) and encourages proposed [
research activities that attempt to merge aective reactions and
information needs.
5.1 Limitations
We designed our survey with the stated aim of gaining understand-
ing of the characterization of the unhappiness of developers and
the causes of unhappiness in software development. We phrased
the questions in our survey by following guidelines from the lit-
erature [
] and from our prior experience with the research
topic [
]. We phrased the questions to avoid priming
specic answers to the respondents. The validation of the questions
was through (1) adopting a psychometrically validated measure-
ment instrument for happiness [
], (2) limiting the remaining
quantitative questions to a demographic nature, and (3) conducting
three pilot runs. We discuss specic threats to validity below.
5.1.1 Internal Validity–Credibility. With respect to the happi-
ness measurement, as reported in Section 2.1, several large scale
studies have found good psychometric properties (reliability and
validity) for SPANE [
], and the instrument was
empirically shown to be consistent across full-time workers and
students [63] and memory recall of events [13, 49].
In order to classify the causes of unhappiness of developers,
we used a qualitative coding process. Whether causality can be
inferred only by controlled experiments is a much-debated issue [
]. Several authors, e.g., [
], maintain that human-oriented
research allows causality to be inferred from the experience of the
participants through qualitative data analysis, provided that there
is a strong methodology for data gathering and analysis. In this
case, our aim was to uncover causes of unhappiness as experienced
by developers themselves. Since we extracted the causes from rst-
hand reports, they should accurately represent the respondents’
views. As far as possible, we have remained faithful to these views
when categorizing the material. The chain of evidence from source
material to results is fully documented and traceable (see the online
appendix [
]). Also, we note that we claim no general relationship
between any specic causes and unhappiness; only experienced
causes of unhappiness are claimed.
A question-order eect [
] could have inuenced the responses
by setting their context. As the present study was conducted in
the context of a larger study on both happiness and unhappiness,
we randomized the order of appearance of the questions related to
aectiveness, thus limiting a potential order eect.
Social desirability bias [
] may have inuenced the answers in
the sense that participants would attempt to appear in a positive
EASE ’17, June 15–16 2017, BTH, Sweden Daniel Graziotin, Fabian Fagerholm, Xiaofeng Wang, and Pekka Abrahamsson
light before the eyes of the enquirer. We limited the bias by inform-
ing the participants that the responses would be anonymous and
evaluated in a statistical form, and addressing the ethical concerns
of the study. In our view, the responses appear candid, indicating
that participants have felt comfortable expressing their true views.
5.1.2 Generalizability–Transferability. Our dataset of software
developers using GitHub is limited with respect to representative-
ness of the average software developer. The data set used in this
study (see Section 3.1) contains only accounts with public activity
during a six-month period. However, it is likely that a signicant
portion of the inactive accounts are not of interest to this study, as
we sought active developers. The degree to which our conclusions
are generalizable beyond the GitHub population may be limited.
For instance, it is possible that the GitHub population is slightly
younger than developers in general. Also, the sample may be bi-
ased towards people that are more comfortable with displaying
their personal performance in public, or face no other kinds of
barriers to doing so (e.g. company policy). However, GitHub is a
reliable source for obtaining research data, allowing replication
of this study on the same or dierent populations. The GitHub
community is large and diverse, with a claim of more than 30 mil-
lion visitors each month [
], many developing open source and
proprietary software, and ranging from solo work to companies and
communities. Furthermore, as shown in Section 4.1, our sample is
well balanced in terms of all demographic characteristics, including
participant role, age, experience, work type, company size, and
student versus worker. By comparing condence intervals, we did
not observe signicant dierences in terms of the SPANE-B score
when varying role (worker, student) or age. This further highlights
the validity and reliability of the SPANE measurement instrument
and the stability of our dataset. Our sample is not evenly balanced
in terms of gender, with males being the vast majority. We believe,
however, that our sample is representative in terms of gender as
well, since males are overrepresented in software engineering jobs,
likely due to gender bias [
]. In summary, we consider our
sample to be large and diverse enough to warrant claims regarding
software developers to the extent possible in a single study. Further
replication is necessary to validate the ndings and obtain details
on demographic subgroups.
5.2 Recommendations for Practitioners
Our study has found a plethora of causes of unhappiness of devel-
opers that are of interest to practitioners regardless of their roles.
We summarized the most prominent ones in the present paper, but
practitioners could be interested in the complete list of factors and
occurrences that is freely available online as open data [31].
Team members may be interested in the causes of unhappi-
ness for enabling self-regulation and emotional capability mecha-
nisms [
] for reducing personal and group unhappiness. For similar
reasons, managers should carefully attempt to understand the un-
happiness of developers using the present paper as support. Those
in leadership positions should attempt to foster happiness by limit-
ing unhappiness. Previous research (e.g., [
]) has shown
that the benets of fostering happiness among developers are sub-
stantial especially in terms of software development productivity
and software quality. In a related paper on the consequences of
unhappiness of developers, we found that addressing unhappiness
could limit damage on dierent aspects of software development,
including developers, artifacts, and development processes [
We believe that the results of the present study will potentially
enhance the working conditions of software developers. This is
corroborated by previous research [
] suggesting that intervening
on the aect of developers may yield large benets at low cost.
Furthermore, the vast majority of the causes of unhappiness are
of external type. Since external causes may be easier to inuence
than internal causes, and since inuencing them will impact several
developers rather than only one at a time, this suggests that there
are plenty of opportunities to improve conditions for developers in
5.3 Implications for Researchers
We believe that the results of the present work can spawn several
important future research directions. A limited set of the found
causes of unhappiness has been investigated previously in the soft-
ware engineering literature. However, while the previous work
oers valuable results, it appears limited either because of being
framed too generally in psychology research – resulting in ndings
regarding general job performance settings – or due to a narrow
focus on a single emotion (e.g., frustration). The framing oered
by the present study sheds new light on these previous studies
by considering them in terms of happiness and aect. Here, we
suggest three implications for research that we believe are of high
importance and priority.
Our result regarding the distribution of happiness among devel-
opers suggests that happiness – in terms of the SPANE instrument
score – is centered around 9
05, higher than what may be expected
based on other studies using the instrument. Our question for fu-
ture research is to understand whether a) a higher relativity should
be embraced when analyzing the aect of developers and its im-
pact on software engineering outcomes, or b) developers require
tailored measurement instruments for their happiness as if they
are a special population. Validating the score through replication,
and, if it is found to be stable, investigating the reasons for it being
higher than in several other populations, are important aims for
future research.
As reported in the previous section, most causes of unhappiness
are of external type and they may be easier to inuence than internal
causes. We see that much research is needed in order to understand
the external causes and how to limit them.
Finally, the present study highlights how studies of human as-
pects in software engineering are important for the empirical un-
derstanding of how software development can be improved. Many
questions in software engineering research require approaches
from behavioral and social sciences; we perceive a need in aca-
demic discourse to reect on how software engineering research
can be characterized and conducted in terms of such paradigms.
Software engineering studies on human factors often call for
further human aspects studies. Yet, we believe that the present study
calls for much technical research as well, because the highest source
of unhappiness among software developers is related to artifacts
and working with artifacts. One example is related to debugging
and bug xing, as they appear often in the causes of unhappiness.
On the Unhappiness of Soware Developers EASE ’17, June 15–16 2017, BTH, Sweden
This suggests that much research is needed for supporting humans
in the maintenance of software, e.g. in terms of information needs
and mechanisms for strategic coordination of the workforce and
the software architecture. Furthermore, emotional support with
respect to software maintenance might support higher quality of
the desired output.
In this paper, we presented a mixed method large-scale survey
(1 318 complete and valid responses) to broaden the understanding
of unhappiness among software developers.
Our key contributions are as follows, and are publicly archived
as open access and open data [31]:
(C1) An estimate of the distribution of (un)happiness among
software developers and (C2) An analysis of the experienced causes
for unhappiness among software developers while developing soft-
Our results show that software developers are a slightly happy
population. The consequences of that result need to be explored in
future studies. Nevertheless, the results do not remove the need for
limiting the unhappiness of developers, who have repeatedly asked
to be given a voice through research and in the design of studies.
The results of our study have also highlighted 219 fascinating
factors about the causes of unhappiness while developing software.
These should be further explored in future research and used as
guidelines by practitioners in management positions and developers
in general for fostering happiness on the job.
The authors would like to thank all those who participated in this
study. Daniel Graziotin has been supported by the Alexander von
Humboldt (AvH) Foundation.
A E Akgün, Halit Keskin, John C Byrne, Ayse Gunsel, Ali E Akgun, Halit Keskin,
John C Byrne, and Ayse Gunsel. 2011. Antecedents and Results of Emotional
Capability in Software Development Project Teams. Journal of Product Innovation
Management 28, 6 (2011), 957–973.
James E Bartlett, Joe W Kotrlik, and Chadwick C Higgins. 2001. Organizational
Research: Determining Appropriate Sample Size in Survey Research. Information
Technology, Learning, and Performance Journal 19, 1 (2001), 43–50.
A Ben-Zeév. 2010. Are negative emotions more important than positive emotions?
Number 7. Psychology Today.
W G Cochran. 1977. Sampling Techniques. John Wiley & Sons, New York, USA.
Juliet M Corbin and Anselm L Strauss. 2008. Basics of Qualitative Research: Tech-
niques and Procedures for Developing Grounded Theory (3 ed.). Sage Publications,
Giulia Corno, Guadalupe Molinari, and Rosa Maria Baños. 2016. Assessing
positive and negative experiences: validation of a new measure of well-being in
an Italian population. Rivista di psichiatria 51, 3 (2016), 110–115.
John W Creswell. 2009. Research design: qualitative, quantitative, and mixed
method approaches (3 ed.). Vol. 2. Sage Publications, Thousand Oaks, California.
Bill Curtis, Herb Krasner, and Neil Iscoe. 1988. A Field Study of the Software
Design Process for Large Systems. Commun. ACM 31, 11 (Nov. 1988), 1268–1287.
Munmun De Choudhury and Scott Counts. 2013. Understanding aect in the
workplace via social media. In Proceedings of the 2013 conference on Computer
supported cooperative work - CSCW ’13. ACM Press, New York, New York, USA,
[10] Peter J Denning. 2012. Moods. Commun. ACM 55, 12 (Dec. 2012), 33.
Giuseppe Destefanis, Marco Ortu, Steve Counsell, Stephen Swift, Michele March-
esi, and Roberto Tonelli. 2016. Software development: do good manners matter?
PeerJ Computer Science 2, 4 (2016), e73.
Ed Diener, Eunkook M Suh, Richard E Lucas, and Heidi L Smith. 1999. Subjective
well-being: Three decades of progress. Psychological Bulletin 125, 2 (1999),
Ed Diener, Derrick Wirtz, William Tov, Chu Kim-Prieto, Dong-won Choi, Shige-
hiro Oishi, and Robert Biswas-Diener. 2010. New Well-being Measures: Short
Scales to Assess Flourishing and Positive and Negative Feelings. Social Indicators
Research 97, 2 (May 2010), 143–156.
Yanyi K Djamba and W Lawrence Neuman. 2002. Social Research Methods:
Qualitative and Quantitative Approaches. Teaching Sociology 30, 3 (July 2002),
Brian Doll. 2015. A closer look at Europe. (2015).
a-closer-look-at-europe [Retrieved: 2017-01-26].
Graham A du Plessis and Tharina Guse. Validation of the Scale of Positive and
Negative Experience in a South African student sample. South African Journal of
Psychology (????). Prepublished June 27, 2016, DOI: 10.1177/0081246316654328.
Steve Easterbrook, Janice Singer, Margaret-Anne Storey, and Daniela Damian.
2008. Selecting empirical methods for software engineering research. In Guide
to Advanced Empirical Software Engineering. Springer, 285–311.
Fabian Fagerholm. 2015. Software Developer Experience: Case Studies in Lean-Agile
and Open Source Environments. Ph.D. Dissertation. Department of Computer
Science, University of Helsinki. Series of Publications A, Report A-2015-7.
Fabian Fagerholm, Marko Ikonen, Petri Kettunen, Jürgen Münch, Virpi Roto,
and Pekka Abrahamsson. 2014. How Do Software Developers Experience Team
Performance in Lean and Agile Environments?. In Proceedings of the 18th Inter-
national Conference on Evaluation and Assessment in Software Engineering (EASE
’14). ACM, New York, NY, USA, Article 7, 7:1–7:10 pages.
Fabian Fagerholm, Marko Ikonen, Petri Kettunen, Jürgen Münch, Virpi Roto,
and Pekka Abrahamsson. 2015. Performance Alignment Work: How software
developers experience the continuous adaptation of team performance in Lean
and Agile environments. Information and Software Technology 64 (2015), 132–147.
Cynthia D Fisher. 2000. Mood and emotions while working: missing pieces of
job satisfaction? Journal of Organizational Behavior 21, 2 (March 2000), 185–202.
Denae Ford and Chris Parnin. 2015. Exploring causes of frustration for software
developers. In CHASE ’15: Proceedings of the Eighth International Workshop on
Cooperative and Human Aspects of Software Engineering. North Carolina State
University, IEEE Press.
Denae Ford, Justin Smith, Philip J. Guo, and Chris Parnin. 2016. Paradise Un-
plugged: Identifying Barriers for Female Participation on Stack Overow. In
Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Founda-
tions of Software Engineering (FSE 2016). ACM, New York, NY, USA, 846–857.
B L Fredrickson. 2001. The role of positive emotions in positive psychology:
The broaden-and-build theory of positive emotions. American Psychologist 56, 3
(2001), 218–226.
T Fritz and G C Murphy. 2011. Determining relevancy: how software developers
determine relevant information in feeds. In ACM Conference on Human Factors
in Computing Systems (CHI). 1827–1830.
A Furnham. 1986. Response bias, social desirability and dissimulation. Personality
and Individual Dierences 7, 3 (1986), 385–400.
J Gläser and G Laudel. 2013. Life With and Without Coding: Two Methods for
Early-Stage Data Analysis in Qualitative Research Aiming at Causal Explanations.
Forum Qualitative Sozialforschung / Forum: Qualitative Social Research (2013).
Georgios Gousios, Margaret-Anne Storey, and Alberto Bacchelli. 2016. Work
Practices and Challenges in Pull-based Development: The Contributor’s Perspec-
tive. In Proceedings of the 38th International Conference on Software Engineering
(ICSE ’16). ACM, New York, NY, USA, 285–296.
Daniel Graziotin. 2016. Software quality information needs. Research Ideas and
Outcomes 2 (2016), e8865.
Daniel Graziotin, Fabian Fagerholm, Xiaofeng Wang, and Pekka Abrahamsson.
2017. Consequences of Unhappiness While Developing Software. Submitted.
Daniel Graziotin, Fabian Fagerholm, Xiaofeng Wang, and Pekka Abrahamsson.
2017. Online appendix: the happiness of software developers. gshare (2017).gshare.c.3355707.
Daniel Graziotin, Xiaofeng Wang, and Pekka Abrahamsson. 2014. Do feel-
ings matter? On the correlation of aects and the self-assessed productivity in
software engineering. Journal of Software: Evolution and Process 27, 7 (2014),
Daniel Graziotin, Xiaofeng Wang, and Pekka Abrahamsson. 2014. Happy soft-
ware developers solve problems better: psychological measurements in empirical
software engineering. PeerJ 2 (2014), e289.
D Graziotin, X Wang, and P Abrahamsson. 2014. Software Developers, Moods,
Emotions, and Performance. IEEE Software 31, 4 (2014), 24–27.
[35] Daniel Graziotin, Xiaofeng Wang, and Pekka Abrahamsson. 2015. How do you
feel, developer? An explanatory theory of the impact of aects on programming
performance. PeerJ Computer Science 1, 1 (Aug. 2015), e18.
Daniel Graziotin, Xiaofeng Wang, and Pekka Abrahamsson. 2015. The Aect of
Software Developers: Common Misconceptions and Measurements. In Proceed-
ings of the Eighth International Workshop on Cooperative and Human Aspects of
Software Engineering (CHASE ’15). IEEE Press, Piscataway, NJ, USA, 123–124.
EASE ’17, June 15–16 2017, BTH, Sweden Daniel Graziotin, Fabian Fagerholm, Xiaofeng Wang, and Pekka Abrahamsson
Daniel Graziotin, Xiaofeng Wang, and Pekka Abrahamsson. 2015. Understanding
the aect of developers: theoretical background and guidelines for psychoem-
pirical software engineering. In SSE 2015: Proceedings of the 7th International
Workshop on Social Software Engineering. ACM, 25–32.
Ilya Grigorik. 2012. GitHub Archive. (2012). [Retrieved:
Daniel M Haybron. 2001. Happiness and Pleasure. Philosophy and Phenomeno-
logical Research 62, 3 (May 2001), 501–528.
Daniel M Haybron. 2005. On Being Happy or Unhappy. Philosophy and Phe-
nomenological Research 71, 2 (Sept. 2005), 287–317.
Watts Humphrey. 1996. Managing Technical People: Innovation, Teamwork, and
the Software Process. Addison-Wesley Professional.
Veljko Jovanović. 2015. Beyond the PANAS: Incremental validity of the Scale of
Positive and Negative Experience (SPANE) in relation to well-being. Personality
and Individual Dierences 86 (2015), 487–491.
Daniel Kahneman. 1999. Objective Happiness. In Well-Being: Foundations of
Hedonic Psychology, Daniel Kahneman, Ed Diener, and Norbert Schwarz (Eds.).
Utilitas, New York, NY, USA, 3–25.
Iftikhar Ahmed Khan, Willem-Paul Brinkman, and Robert M Hierons. 2010. Do
moods aect programmers’ debug performance? Cognition, Technology & Work
13, 4 (2010), 245–258.
Barbara Kitchenham, Lech Madeyski, David Budgen, Jacky Keung, Pearl Brereton,
Stuart Charters, Shirley Gibbs, and Amnart Pohthong. 2016. Robust Statistical
Methods for Empirical Software Engineering. Empirical Software Engineering
(June 2016), 1–52.
Robert V Krejcie and Daryle W Morgan. 1970. Determining Sample Size for
Research Activities. Educational and Psychological Measurement 30, 3 (Sept. 1970),
Per Lenberg, Robert Feldt, and Lars-Göran Wallgren. 2015. Behavioral software
engineering. Journal of Systems and Software 107, C (Sept. 2015), 15–37.
Andrew C Leon, Lori L Davis, and Helena C Kraemer. 2011. The role and
interpretation of pilot studies in clinical research. Journal of Psychiatric Research
45, 5 (2011), 626–629.
Feng Li, Xinwen Bai, and Yong Wang. 2013. The Scale of Positive and Negative
Experience (SPANE): psychometric properties and normative data in a large
Chinese sample. PloS one 8, 4 (4 2013), 1–9.
S Lyubomirsky, L King, and E Diener. 2005. The benets of frequent positive
aect: does happiness lead to success? Psychological bulletin 131, 6 (2005),
Mika Mäntylä, Bram Adams, Giuseppe Destefanis, Daniel Graziotin, and Marco
Ortu. 2016. Mining valence, arousal, and dominance: possibilities for detecting
burnout and productivity?. In MSR ’16: Proceedings of the 13th International
Conference on Mining Software Repositories. Brunel University, ACM, New York,
New York, USA, 247–258.
A M Marino and J Zabojnik. 2008. Work-related perks, agency problems, and
optimal incentive contracts. The RAND Journal of Economics 39, 2 (June 2008),
Tim Miller, Sonja Pedell, Antonio A Lopez-Lorca, Antonette Mendoza, Leon
Sterling, and Alen Kerinan. 2015. Emotion-led modelling for people-oriented
requirements engineering: The case study of emergency systems. The Journal of
Systems and Software 105 (2015), 54–71.
Sebastian C Muller and Thomas Fritz. 2015. Stuck and Frustrated or in Flow
and Happy: Sensing Developers’ Emotions and Progress. In 2015 IEEE/ACM 37th
IEEE International Conference on Software Engineering. IEEE, 688–699.
A N Oppenheim. 1992. Questionnaire Design and Attitude Measurement (2 ed.).
Bloomsbury Academic, London, UK.
Marco Ortu, Bram Adams, Giuseppe Destefanis, Parastou Tourani, Michele
Marchesi, and Roberto Tonelli. 2015. Are Bullies More Productive? Empirical
Study of Aectiveness vs. Issue Fixing Time. In 2015 IEEE/ACM 12th Working
Conference on Mining Software Repositories (MSR). IEEE, 303–313.
Marco Ortu, Giuseppe Destefanis, Steve Counsell, Stephen Swift, Michele March-
esi, and Roberto Tonelli. 2016. How diverse is your team? Investigating gender
and nationality diversity in GitHub teams. Peerj Preprints 4:e2285v1 (2016).
R Core Team. 2016. R: A Language and Environment for Statistical Computing. R
Foundation for Statistical Computing, Vienna, Austria. https://www.R-project.
Rakesh Rana, Miroslaw Staron, Christian Berger, Agneta Nilsson, Riccardo Scan-
dariato, Alexandra Weilenmann, and Martin Rydmark. 2015. On the role of
cross-disciplinary research and SSE in addressing the challenges of the digitaliza-
tion of society. In 2015 6th IEEE International Conference on Software Engineering
and Service Science (ICSESS). IEEE, 1106–1109.
William Revelle. 2016. psych: Procedures for Psychological, Psychometric, and
Personality Research. Northwestern University, Evanston, Illinois. http://CRAN. R package version 1.6.6.
James A Russell. 2003. Core aect and the psychological construction of emotion.
Psychological review 110, 1 (2003), 145–172.
Lee Sigelman. 1981. Question-Order Eects on Presidential Popularity. Public
Opinion Quarterly 45, 2 (June 1981), 199–207.
Ana Junça Silva and António Caetano. 2013. Validation of the Flourishing Scale
and Scale of Positive and Negative Experience in Portugal. Social Indicators
Research 110, 2 (2013), 469–478.
Katsunori Sumi. 2014. Reliability and Validity of Japanese Versions of the Flour-
ishing Scale and the Scale of Positive and Negative Experience. Social Indicators
Research 118, 2 (2014), 601–615.
Josh Terrell, Andrew Konk, Justin Middleton, Clarissa Rainear, Emerson
Murphy-Hill, Chris Parnin, and Jon Stallings. 2016. Gender dierences and bias
in open source: Pull request acceptance of women versus men. Peerj Preprints
4:e1733v2 (2016).
E R Thompson. 2007. Development and Validation of an Internationally Reliable
Short-Form of the Positive and Negative Aect Schedule (PANAS). Journal of
Cross-Cultural Psychology 38, 2 (March 2007), 227–242.
Jeanne L Tsai, Brian Knutson, and Helene H Fung. 2006. Cultural variation in
aect valuation. Journal of Personality and Social Psychology 90, 2 (Feb. 2006),
Robert P Vecchio. 2000. Negative Emotion in the Workplace: Employee Jealousy
and Envy. International Journal of Stress Management 7, 3 (2000), 161–179.
David Watson, Lee A Clark, and Auke Tellegen. 1988. Development and validation
of brief measures of positive and negative aect: The PANAS scales. Journal of
Personality and Social Psychology 54, 6 (June 1988), 1063–1070.
Michal R Wrobel. 2013. Emotions in the software development process. 2013 6th
International Conference on Human System Interactions (HSI) (2013), 518–523.
Taro Yamane. 1967. Statistics: An introductory analysis. Harper and Row, New
York City, US.
J M Zelenski, S A Murphy, and D A Jenkins. 2008. The Happy-Productive Worker
Thesis Revisited. Journal of Happiness Studies 9, 4 (2008), 521–537.
... Software companies nowadays often aim for flourishing happi-ness among developers. There are several ways to make software developers happy, for instance [44]: Perks, playground rooms, free breakfast, remote office options, sports facilities near the companies, etc. Graziotin et al. present several studies [44][45][46][47][48][49], which relate developers' happiness with productivity, solving problems in a better way, better performance, and so on. ...
... Programmers go through positive and negative emotions [29] in software development activities. Based on this, we considered a set of emotions, both positive and negative, supported by proposals extracted from [44][45][46][47][48][49]. ...
... The most comprehensive list we identified was recently published by Masood et al. [10]. As part of their work, the authors surveyed literature on software development tasks and activities, and synthesized a list of example tasks and their categorization, primarily building on the work of Meyer et al. [21], Licorish and MacDonell [22], Graziotin et al. [23], Ford and Parnin [24], Milewski [25], Glass et al. [26], Murgia et al. [27], and Madampe et al. [28]. We manually analysed the examples (from Table I of Masood et al. [10]) and split them into separate activities where applicable, e.g., extracting the activities "assign GitHub issues" and "review pull requests" from the example "Assigning GitHub issue or reviewing pull request", for a total of 56 software engineering tasks. ...
Full-text available
Implicit gender bias in software development is a well-documented issue, such as the association of technical roles with men. To address this bias, it is important to understand it in more detail. This study uses data mining techniques to investigate the extent to which 56 tasks related to software development, such as assigning GitHub issues and testing, are affected by implicit gender bias embedded in large language models. We systematically translated each task from English into a genderless language and back, and investigated the pronouns associated with each task. Based on translating each task 100 times in different permutations, we identify a significant disparity in the gendered pronoun associations with different tasks. Specifically, requirements elicitation was associated with the pronoun "he" in only 6% of cases, while testing was associated with "he" in 100% of cases. Additionally, tasks related to helping others had a 91% association with "he" while the same association for tasks related to asking coworkers was only 52%. These findings reveal a clear pattern of gender bias related to software development tasks and have important implications for addressing this issue both in the training of large language models and in broader society.
... Our response rate was thus 8.9%, which is in line with that of prior studies surveying developers on GitHub. Graziotin et al., for example, reported a 7% response rate and a share of 96.6% of deliverable emails [34]. ...
Background: Risk-taking is prevalent in a host of activities performed by software engineers on a daily basis, yet there is scant research on it. Aims and Method: We study if software engineers' risk-taking is affected by framing effects and by software engineers' personality. To this end, we perform a survey experiment with 124 software engineers. Results: We find that framing substantially affects their risk-taking. None of the "Big Five" personality traits are related to risk-taking in software engineers after correcting for multiple testing. Conclusions: Software engineers and their managers must be aware of framing effects and account for them properly.
... The authors utilised Parrot's framework to categorise the comments manually and compared each author's labels to check the level of agreement. Graziotin et al. [78] investigated qualitatively the causes of unhappiness emotion and found that the causes were from external factors (i.e., artifacts and working with other developers, bugs and their fixes, technical infrastructure, requirements, process-related factors) and internal factors (e.g., the developer's own being). Furthermore, Guzman [74] built a prototype to visualise the topics presented in the software collaboration artifacts: the prototype gave a general overview of the content presented in all analysed artifacts. ...
Full-text available
Context Burnout is a work-related syndrome that, similar to many occupations, influences most software developers. For decades, studies in software engineering(SE) have explored the causes of burnout and its consequences among IT professionals. Objective This paper is a systematic mapping study (SMS) of the studies on burnout in SE, exploring its causes and consequences, and how it is studied (e.g., choice of data). Method We conducted a systematic mapping study and identified 92 relevant research articles dating as early as the early 1990s, focusing on various aspects and approaches to detect burnout in software developers and IT professionals. Results Our study shows that early research on burnout was primarily qualitative, which has steadily moved to more quantitative, data-driven in the last decade. The emergence of machine learning (ML) approaches to detect burnout in developers has become a de-facto standard. Conclusion Our study summarizes what we now know about burnout, how software artifacts indicate burnout, and how machine learning can help its early detection. As a comprehensive analysis of past and present research works in the field, we believe this paper can help future research and practice focus on the grand challenges ahead and offer necessary tools.
... Affects PANAS -Scale of positive and negative affects [5,28,29] SPANE -Scale of positive and negative experiences [4,17,53] Well-being Affective well-being with work by Sevastos (1996) and Watson and Clark (1992) [29,47] Subjective/psychological well-being Index of psychological well-being [30,35,47] Happiness Oxford Happiness Questionnaire [16,37] Happiness at work Work-related affective well-being scale [45,49] Life satisfaction Life satisfaction scale [4,5,20,21] Intrinsic job satisfaction The intrinsic satisfaction questionnaire a developed by Cook and Mal (1981) [29,45] Job satisfaction Job satisfaction scale [5,28,35] ...
Full-text available
Globalisation and intensifying competition force organisations to create distinctive competitive advantages, transforming classic management models and seeking effective responses to the mutability and dynamics of markets. People management plays a central role in achieving differentiating capacities, forcing more effective management of human resources. In an environment marked by high absenteeism and turnover, followed by the growing difficulty in retaining talent, organisations have been seeking to increase the satisfaction of internal customer needs (employees), working on issues such as well-being and happiness at work. The increasing concern with employee well-being and their association with job performance have been the basis for many research studies aimed at understanding the impact of the concept of happiness on employee behaviour and performance. This chapter seeks to summarise the main ways of operationalising the constructs inherent to the thesis of the happy-productive worker (happiness and performance). This chapter is structured as follows: introduction, exploration of the happy-productive worker thesis (concept and origin and main theoretical frameworks related to the idea), measuring the constructs (happiness and performance), and conclusion.
Full-text available
The increasing essential complexity of software systems makes current software engineering methods and practices fall short in many occasions. Software assistants have the ability to help humans achieve a variety of tasks, including the development of software. Such assistants, which show human‐like competences such as autonomy and intelligence, help software engineers do their job by empowering them with new knowledge. This article investigates the research efforts that have been conducted on the creation of assistants for software design, construction and maintenance paying special attention to the user‐assistant interactions. To this end, we followed the standard systematic mapping study method to identify and classify relevant works in the state of the art. Out of the 7580 articles resulting from the automatic search, we identified 112 primary studies that present works which qualify as software assistants. We provide all the resources needed to reproduce our study. We report on the trends and goals of the assistants, the tasks they perform, how they interact with users, the technologies and mechanisms they exploit to embed intelligence and provide knowledge, and their level of automation. We propose a classification of software assistants based on interactions and present an analysis of the different automation patterns. As outcomes of our study, we provide a classification of software assistants dealing with the design, construction and maintenance phases of software development, we discuss the results, identify open lines of work and challenges and call for new innovative and rigorous research efforts in this field.
Software development is a process that requires a high level of human talent management to ensure its success. This makes it a topic of interest to the software industry and research. Considering this interest, it is evident the need to know the aspects that have been studied, how they have been measured, and what data analysis methods have been used. This paper presents an analysis of the human aspects associated with the software development process, identifying procedures and methods used to analyze data and its measurement. A systematic mapping with a sample of 99 studies identified by their relationship with the proposed topic was used as the research method. The main findings show that one of the most studied is personality. This aspect is related to the performance of software development teams and is a key variable for its conformation. Concerning the most used data source, we find the survey based on self-reporting. Finally, descriptive statistics is the most frequent method of analysis, which is performed prior to other methods such as correlation or regression analysis. The results suggest a wide spectrum of human aspects to be studied in Software Engineering, and interesting potential for analysis by identifying interesting methods other than self-reporting.KeywordsMetricsHuman aspectsSoftware developmentSystematic mapping study
Full-text available
The proliferating literature on the affect of software developers consists mostly of studies investigating the linkage between happiness, software quality, and developers' productivity. Understanding the positive side of happiness - positive emotions and moods - is an attractive and important endeavour. Yet, scholars in industrial and organizational psychology have suggested that studying unhappiness could lead to cost-effective ways of enhancing working conditions, job performance, and to limiting the occurrence of psychological disorders. Furthermore, our comprehension of the consequences of (un)happiness of developers is still too shallow, and it is mainly expressed in terms of development productivity and software quality. In this paper, we attempt to uncover the experienced consequences of unhappiness among programmers while developing software. Using qualitative data analysis of the responses given by 181 questionnaire participants, we identified 49 consequences of unhappiness of software engineers. We found detrimental consequences on developers' mental well-being, the software development process, and the produced artifacts. Our classification scheme, available as open data, will spawn new happiness research opportunities of cause-effect type, and it can act as a guideline for practitioners for identifying detrimental effects of unhappiness and for fostering happiness on the job.
Conference Paper
Full-text available
It is no secret that females engage less in programming fields than males. However, in online communities, such as Stack Overflow, this gender gap is even more extreme: only 5.8% of contributors are female. In this paper, we use a mixed-methods approach to identify contribution barriers females face in online communities. Through 22 semi-structured interviews with a spectrum of female users ranging from non-contributors to a top 100 ranked user of all time, we identified 14 barriers preventing them from contributing to Stack Overflow. We then conducted a survey with 1470 female and male developers to confirm which barriers are gender related or general problems for everyone. Females ranked five barriers significantly higher than males. A few of these include doubts in the level of expertise needed to contribute, feeling overwhelmed when competing with a large number of users, and limited awareness of site features. Still, there were other barriers that equally impacted all Stack Overflow users or affected particular groups, such as industry programmers. Finally, we describe several implications that may encourage increased participation in the Stack Overflow community across genders and other demographics.
Full-text available
Building an effective team of developers is a complex task faced by both software companies and open source communities. The problem of forming a “dream” team involves many variables, including consideration of human factors, and it is not a dilemma solvable in a mathematical way. Empirical studies might provide interesting insights to explain which factors need to be taken into account in building a team of developers and which levers act to optimise collaboration and productivity among developers. In this paper, we present the results of an empirical study aimed at investigating the link between team diver- sity (i.e., gender, nationality) and productivity (issue fixing time). We consider issues solved from the GHTorrent dataset inferring gender and nationality of each team’s members. We also evaluate the politeness of all comments involved in issue resolution. Results show that higher gender diversity is linked with a lower team average issue fixing time and that nationality diversity is linked with lower team politeness.
Full-text available
Biases against women in the workplace have been documented in a variety of studies. This paper presents the largest study to date on gender bias, where we compare acceptance rates of contributions from men versus women in an open source software community. Surprisingly, our results show that women's contributions tend to be accepted more often than men's. However, when a woman's gender is identifiable, they are rejected more often. Our results suggest that although women on GitHub may be more competent overall, bias against them exists nonetheless.
Full-text available
Building an effective team of developers is a complex task faced by both software companies and open source communities. The problem of forming a " dream " team involves many variables, including consideration of human factors, and it is not a dilemma solvable in a mathematical way. Empirical studies might provide interesting insights to explain which factors need to be taken into account in building a team of developers and which levers act to optimise collaboration and productivity among developers. In this paper, we present the results of an empirical study aimed at investigating the link between team diversity (i.e., gender, nationality) and productivity (issue fixing time). We consider issues solved from the GHTorrent dataset inferring gender and nationality of each team's members. We also evaluate the politeness of all comments involved in issue resolution. Results show that higher gender diversity is linked with a lower team average issue fixing time and that nationality diversity is linked with lower team politeness.
Biases against women in the workplace have been documented in a variety of studies. This paper presents a large scale study on gender bias, where we compare acceptance rates of contributions from men versus women in an open source software community. Surprisingly, our results show that women’s contributions tend to be accepted more often than men’s. However, for contributors who are outsiders to a project and their gender is identifiable, men’s acceptance rates are higher. Our results suggest that although women on GitHub may be more competent overall, bias against them exists nonetheless.