PreprintPDF Available

Happiness and the productivity of software engineers

Authors:
Preprints and early-stage research may not have been peer reviewed yet.

Abstract and Figures

Software companies and startups often follow the idea of flourishing happiness among developers. Perks, playground rooms, free breakfast, remote office options, sports facilities near the companies, company retreats, you name it. The rationale is that happy developers should be more productive and also retained. But is it the case that happy software engineers are more productive? Moreover, are perks the way to go to make developers happy? Are developers happy at all? What are the consequences of unhappiness among software engineers? These questions are important to ask both from the perspective of productivity and from the perspective of sustainable software development and well-being in the workplace. Managers, team leaders, as well as team members should be interested in these concerns. This chapter provides an overview of our studies on the happiness of software developers. You will learn why it is important to make software developers happy, how happy they really are, what makes them unhappy, and what is expected regarding happiness and productivity while developing software.
Content may be subject to copyright.
109
© The Author(s) 2019
C. Sadowski and T. Zimmermann (eds.), Rethinking Productivity in Software Engineering,
https://doi.org/10.1007/978-1-4842-4221-6_10
CHAPTER 10
Happiness andthe
Productivity ofSoftware
Engineers
Daniel Graziotin, University of Stuttgart, Germany
Fabian Fagerholm, Blekinge Institute of Technology,
Sweden and University of Helsinki, Finland
Software companies nowadays often aim for flourishing happiness among developers.
Perks, playground rooms, free breakfast, remote office options, sports facilities near the
companies...there are several ways to make software developers happy. The rationale is
that of a return on investment: happy developers are supposedly more productive and,
hopefully, also retained.
But is it the case that happy software engineers = more productive software engineers1?
Moreover, are perks the way to go to make developers happy? Are developers happy at all?
These questions are important to ask both from the perspective of productivity and from
the perspective of sustainable software development and well-being in the workplace.
This chapter provides an overview of our studies on the happiness of software
developers. You will learn why it is important to make software developers happy,
how happy they really are, what makes them unhappy, and what is expected for their
productivity while developing software.
1 In our studies, 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.” [4, page 326].
We also interchange the terms software developer and software engineer so that we do not repeat
ourselves too many times.
110
Why theIndustry Should Strive forHappy
Developers
We could think that happiness is a personal issue that individual developers are
responsible for on their own time. In this line of thinking, software companies should
focus on maximizing the output they get from each developer. However, to get
productive output from a human, we must first invest. As humans, software developers
productivity depends on their skills and knowledge—but to access those, we need to
create favorable conditions that allow the human potential to be realized. As noted
in Chapter 5, developer satisfaction is important for productivity because reduced
satisfaction can incur future costs; it follows that companies should be interested in the
general well-being of their software developers. Furthermore, we believe we should
simply strive to create better working environments, teams, processes, and, therefore,
products.
What Is Happiness, andHow Do WeMeasure It?
This is a very deep question that ancient and modern philosophers have aimed to
answer in more than one book. However, present-day research does give us concrete
insight into happiness and ways to measure it. We define happiness (as many others do)
as a sequence of experiential episodes. Being happy corresponds to frequent positive
experiences, which lead to experiencing positive emotions. Being unhappy corresponds
to the reverse: frequent negative experiences leading to negative emotions. Happiness
is the difference or balance between positive and negative experiences. This balance is
sometimes called affect balance.
The Scale of Positive and Negative Experience (SPANE, [8]) is a recent but valid
and reliable way to assess the affect balance (happiness) of individuals. Respondents
are asked to report on their affect, expressed with adjectives that individuals recognize
as describing emotions or moods, from the past four weeks. This provides a balance
between the sampling adequacy of affect and the accuracy of human memory to recall
experiences and reduce ambiguity. The combination of the scoring of the various items
yields an affect balance (SPANE-B) score, which ranges from -24 (extremely unhappy) to
+24 (extremely happy), where 0 is to be considered a neutral score of happiness.
Chapter 10 happiness andtheproduCtivity ofsoftware engineers
111
Scientific Grounds ofHappy andProductive
Developers
While it is intuitive that happiness is beneficial for productivity and well-being, these
ideas are also supported by scientific research. We have previously shown that happy
developers solve problems better [1], that there is a relationship between affect and how
developers assess their own productivity [2], and that software developers themselves
are calling for research in this area [5]. We have also presented a theory that provides an
explanation of how affect impacts programming performance [3]: events trigger affects
in programmers. These affects might earn importance and priority to a developer’s
cognitive system, and we call them attractors. Together with affects, attractors drive or
disturb programmers’ focus, which impacts their performance. On a larger scale, our
studies show that affect is an important component of performance in software teams
and organizations [11]. Affect is linked to group identity—the feeling of belonging to the
group—affecting cohesion and social atmosphere, which in turn are key factors for team
performance and retention of team members.
We will now consider four important and ambitious questions.
How happy are software developers overall?
What makes them (un)happy?
What happens when they are (un)happy?
Are happy developers more productive?
Answering these questions is challenging. We spent a year designing a comprehensive
study [4, 6] to address them. We needed data from as many software developers
as possible. We also needed as much diversity as possible in terms of age, gender,
geographical location, working status, and other background factors. We designed and
piloted a questionnaire in such a way that the results could be generalizable (with a certain
error tolerance) to the entire population of software developers. Our questionnaire had
demographic questions, SPANE, and open-ended questions asking about developers’
feelings of happiness and unhappiness when developing software. We asked them to
describe a concrete recent software development experience, what could have caused
them to experience their feelings in that situation, and if their software development was
influenced by these feelings in any way, and, if so, how.
We obtained 1,318 complete and valid responses to all our questions.
Chapter 10 happiness andtheproduCtivity ofsoftware engineers
112
How Happy Are Software Developers?
In Figure10-1, you can see how happy our 1,318 participants were.
Our participants had a SPANE-B average score of 9.05, and we estimated the
true mean happiness score of software developers to be between 8.69 and 9.43 with
a 95 percent confidence interval. In other words, most software developers are
moderately happy.
Figure 10-1. Distribution of happiness of software developers (SPANE-B score)
Chapter 10 happiness andtheproduCtivity ofsoftware engineers
113
We compared our results with similar studies (Italian workers, U.S. college students,
Singapore university students, Chinese employees, South African students, and Japanese
college students). All results from other studies reported a mean SPANE-B score higher
than 0 but lower than in our study. Software developers are indeed a slightly happy
group—and they are happier than what we would expect based on knowledge about
various other groups of the human population. This is good news, indeed, but there is
room for improvement nonetheless. Some developers have a negative SPANE-B score,
and there were many examples in the open responses about episodes of unhappiness
that could be avoided.
What Makes Developers Unhappy?
Our analysis of the responses of our 1,318 participants uncovered 219 causes of
unhappiness, which were mentioned 2,280 times in the responses [4]. We present here a
brief summary of the results and the top three categories of things that make developers
unhappy.
The causes of unhappiness that are controllable by managers and team leaders
are mentioned four times as often as those being personal and therefore beyond direct
managerial control. We also expected the majority of the causes to be related to human
aspects and relationships. However, most of them came from technical factors related to
the artifact (software product, tests, requirements and design document, architecture,
etc.) and the process. This highlights the importance of strategic architecture and
workforce coordination.
Being stuck in problem-solving and time pressure are the two most frequent causes
of unhappiness, which corroborates the importance of recent research that attempts to
understand these issues. We recognize that it is in software development’s nature to be
basically problem-solving under deadlines: we cannot avoid problem-solving in software
development. However, developers feel bad when they are stuck and under pressure,
and several detrimental consequences do happen (see the rest of this chapter). This is
where researchers and managers should intervene to reduce the detrimental effects of
time pressure and getting stuck. Psychological grit could be an important characteristic
to train among software developers. Another could be how to switch your mind-set to get
unstuck.
Chapter 10 happiness andtheproduCtivity ofsoftware engineers
114
The third most frequent cause of unhappiness is to work with bad code and, more
specifically, with bad code practices. Developers are unhappy when they produce
bad code, but they suffer tremendously when they meet bad code that could have
been avoided in the first place. As our participants stated, bad code can be a result
of management decisions aiming to save time and effort in the short term. Similar
negative effects were mentioned regarding third persons (such as colleagues, team
leaders, or customers) who make developers feel inadequate with their work, forced
repetitive mundane tasks, and imposed limitations on development. Many of the
negative consequences can be avoided by rotating tasks, by making better decisions,
and by actually listening to developers. Several top causes are related to perceptions
of inadequacy of the self and others, validating recent research activities related to
interventions that improve the affect of developers [3].
Finally, we see that factors related to information needs in terms of software quality
and software construction are strong contributors to unhappiness among developers.
Chapter 24 shows an example of how current software tools may overload developers
with information and illustrates how problems related to information flow could be
solved for individual developers, teams, and organizations. More research is needed on
producing tools and methods that make communication and knowledge management
in software teams easier and that help effortlessly store, retrieve, and comprehend
information in all stages of the software development life cycle.
What Happens When Developers Are Happy (or Unhappy)?
We classified the answers to our open-ended questions and found dozens of causes
and consequences of happiness and unhappiness while developing software [4, 6].
Developers in our study reported a variety of consequences of being unhappy. We
have summarized these consequences in Figure10-2. There is a pictogram for each
major consequence, and they are divided into internal and external consequences. The
internal consequences, pictured inside the mind of the developer, are directed toward
developers themselves and have a personal impact. The external consequences are ones
that have an effect outside the individual developer. They might impact a project, the
development process, or a software artifact.
Chapter 10 happiness andtheproduCtivity ofsoftware engineers
115
As you can see, developers reported several productivity-related consequences—and
some even explicitly reported experiencing lower productivity. Other consequences
include delays, process deviations, low code quality, throwing away code, and breaking
the process flow in projects. These external effects are direct impacts on productivity
and performance. Internal consequences, such as low motivation and reduced cognitive
performance, indirectly affect productivity as well. Work withdrawal and mental unease,
or, in the worst case, signs of disorders, are among the gravest consequences mentioned
that impact developers personally.
For the purposes of this chapter, it is worth going into more detail on the
consequences of happiness and unhappiness, because several of them are productivity-
related and productivity was the most populated category of consequences. We are
reporting them in an order that favors narrative, not by frequency of occurrence.
Figure 10-2. Consequences of unhappiness while developing software. Available
as CC-BY from Graziotin etal. [16]
Chapter 10 happiness andtheproduCtivity ofsoftware engineers
116
Cognitive Performance
We found that being happy or unhappy influences several factors related to cognitive
performance, that is, how we efficiently process information in our brain. Happiness
and unhappiness influence how we can focus while coding, as put by one participant:
“[…] The negative feelings lead to not thinking things through as clearly as I would
have if the feeling of frustration was not present.” The opposite also holds true: “My
software development is influenced because I can be more focused on my tasks and
trying to solve one problem over another.” As the focus can be higher when happy (or
lower when unhappy), a natural consequence is that problem-solving abilities are
influenced: “I mean, I can write codes and analyze problems quickly and with lesser
or no unnecessary errors when I’m not thinking of any negative thoughts.” Being
happy while developing software brings higher learning abilities: “It made me want to
pursue a master’s in computer science and learn interesting and clever ideas to solve
problems.” However, being unhappy causes mental fatigue, and participants reported
“getting frustrated and sloppy.
Flow
Participants mentioned how being unhappy caused breaks in their flow. Flow is a state
of intense attention and concentration resulting from task-related skills and challenges
being in balance (see more about that in Chapter 23). 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.” When happy,
developers can enter a state of sustained flow. They feel full of energy and with strong
focus. In such a state, they are “unaware of time passing.” They can “continue to code
without any more errors for the rest of the day” and “just knock out lines of code all day,
with “dancing fingers.” Flow is related to mindfulness, which is discussed in Chapter 25.
Motivation andWithdrawal
Motivation was often mentioned by our participants. They were clear in stating that
unhappiness leads to low motivation for developing software: “[The unhappiness]
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 punishment.” The
participants also stated that increased motivation occurred when they were happy.
Chapter 10 happiness andtheproduCtivity ofsoftware engineers
117
Unhappiness and happiness are causes of work withdrawal and work engagement,
respectively. Work withdrawal is a destructive consequence of unhappiness, and
it emerged often among the responses. Work withdrawal is a family of behaviors
that is defined as employees’ attempts to remove themselves, either temporarily or
permanently, from daily work tasks. We found varying degrees of work withdrawal,
ranging from switching to another task (“[…] You spend like two hours investigating on
Google for a similar issue and how it was resolved, you find nothing, and desperation
kicks in.”) 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 quitting
the job. High work engagement and perseverance, on the other hand, were reported to
occur when respondents were happy. This means, for example, pushing forward with
a task: “I think I was more motivated to work harder the next few hours.” This is slightly
different from motivation, which is more about the energy directed to acting toward a
goal. Work engagement is committing to the act of moving toward a goal.
Happiness andUnhappiness, andHow They Relate
totheProductivity ofDevelopers
Finally, participants directly mentioned how unhappiness hinders their productivity.
We grouped all responses related to performance and productivity losses. The
responses within this category ranged from simple and clear (“productivity drops”
and “[Negative experience] definitely makes me work slower”) to more articulated
(“[Unhappiness] made it harder or impossible to come up with solutions or with good
solutions.”). Unhappiness also causes delays in executing process activities: “In both
cases [negative experiences] the emotional toll on me caused delays to the project.” Of
course, participants reported that happiness leads to high productivity: “When I have
this [happy] feeling, I can just code for hours and hours,” “I felt that my productivity
grew while I was happy,” and “The better my mood, the more productive I am.” Here
are more details on that by one participant: “I become productive, focused, and enjoy
what I’m doing without wasting hours looking here and there in the code to know how
things are hooked up together.” An interesting aspect is that, when happy, developers
tend to take on undesired tasks: “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.” On the other hand, unhappy developers could be so unproductive that
they become destructive. We found some instances of participants who destroyed the
task-related codebase (“I deleted the code that I was writing because I was a bit angry”)
Chapter 10 happiness andtheproduCtivity ofsoftware engineers
118
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.”). Another intriguing aspect is about
long-term considerations of being happy: “I find that when I feel [happy], I’m actually
more productive going into the next task, and I make better choices in general for the
maintenance of the code long-term. […] I’m more likely to comment code thoroughly.
Are Happy Developers More Productive?
But are happy developers really more productive? Whenever science attempts to show if
a factor X causes an outcome Y, researchers design controlled experiments. Controlled
experiments attempt to keep every possible factor constant (A, B, C, ...) except for the
factors (X) that should cause a change to the outcome Y. You can find more about
controlled experiments in Chapter 9. Whenever this control is not possible, we call these
studies quasi-experiments.
Here is the issue with research on happiness: it is challenging to control the
happiness (or the mood, the emotions) of people. One of the reasons is that a perfectly
controlled experiment would need to be quite unethical to make the unhappy control
group truly unhappy. The effects of asking participants to remember sad events, or
showing depressing photographs, is negligible. Still, we set up two quasi-experiments to
observe some correlations.
One of these studies [1] has received considerable media attention. We tested a
hypothesis regarding a difference of intellectual (cognitive-driven) performance in
terms of the analytical (logical, mathematical) problem-solving of software engineers
according to how happy they were. We also wanted to perform a study where all the tools
and measurements came from psychology research and were validated. So, we designed
a quasi-experiment in a laboratory, where 42 BSc and MSc students of computer science
had their happiness measured and then conducted a task resembling algorithmic
design. For measuring happiness, we opted for SPANE (explained previously).
The analytic task was similar to algorithm design and execution. We decided to
administer the Tower of London test (also known as Shallice test) to our participants.
The Tower of London test resembles the Tower of Hanoi game. The test comprises
two boards with stacks and several colored beads. There are usually three stacks per
board, and each stack can accommodate only a limited number of beads. The first
board presents predefined stacked beads. The participants received the second board,
which has the same beads as the first board but stacked in a different configuration. The
Chapter 10 happiness andtheproduCtivity ofsoftware engineers
119
participants have to re-create the configuration of the first board by unstacking one bead
at a time and moving it to another stack. The Psychology Experiment Building Language
(PEBL) is an open source language and a suite of neuropsychology tests [13, 14]. The
Tower of London test is among them.
PEBL was able to collect the measures that let us calculate a score for the analytic
performance. We compared the scores obtained in both tasks with the happiness of
developers. The results showed that the happiest software developers outperformed
the other developers in terms of analytic performance. We estimated the performance
increase to be about 6 percent. The performance increase was not negligible, and we
confirmed it by measuring Cohen’s d statistic. Cohen’s d is a number usually ranging
from 0 to 2, which represents the magnitude of the effect size of a difference of means.
Our Cohen’s d for the difference between the two groups mean was 0.91—a large effect
given that we did not obtain extreme cases of happiness and unhappiness. The margins
could even be higher than that.
In another study [2], we did something more esoteric. We aimed to continue using
psychology theory and measurement instruments for understanding the linkage
between the real-time affect (let’s say happiness) raised by a software development task
and the productivity related to the task itself. Eight software developers (four students
and four from software companies) worked on their real-world software project. The
task length was 90 minutes (as it is about the typical length for a programming task).
Each ten minutes, the developers filled a questionnaire formed by the Self-Assessment
Manikin (SAM) and an item for self-assessing the productivity.
SAM is a scale for assessing an emotional state or reaction. SAM is peculiar because
it is a validated way to measure the affect raised by a stimulus (like an object, or a
situation) and it is picture-based (no words). SAM is simply three rows of puppets with
different face expressions and body language. Therefore, it is quick for a participant
to fill SAM, especially if implemented on a tablet (only three touches). We analyzed
how developers felt during the task and how they self-assessed themselves in terms of
productivity. Self-assessment is not a very objective way of measuring productivity, but
it has been demonstrated that individuals are actually good at self-assessing themselves
if they are observed alone [15]. The results have shown that high pleasure with the
programming task and the sensation of having adequate skills are positively correlated
with the productivity. This correlation holds over time. We also found that there are
strong variations of affect in 90 minutes of time. Happy software developers are indeed
more productive.
Chapter 10 happiness andtheproduCtivity ofsoftware engineers
120
Potential Impacts ofHappiness onOther Outcomes
Happiness influences so many things besides productivity, most of which are still related
to development performance. Here we list three of them.
Unhappiness causes glitches in communication and a disorganized process:
“Miscommunication and disorganization made it very difficult to meet deadlines.” But
happy developers can also mean more collaborative team members, leading to increased
collaboration. Often, we saw a repeating pattern of willingness to share knowledge (“I’m very
curious, and I like to teach people what I learned”) and to join an effort to solve a problem
(“We never hold back on putting our brains together to tackle a difficult problem or plan a
new feature”), even when not related to the task at hand or the current responsibilities (“I
was more willing to help them with a problem they were having at work.”).
Being happy or unhappy influences not only the productivity of the code writing
process but also the quality of the resulting code. Participants reported that “Eventually
[due to negative experiences], code quality cannot 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.” Sometimes, being unhappy
results in discharging quality practices (“[...] so I cannot follow the standard design
pattern”) as a way to cope with the negative experiences. Yet, being happy improves
the quality of code. A participant told a small story about their work: “I was building
an interface to make two applications 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.” When happy, developers tend to make less mistakes, see solutions to
problems more easily, and make new connections to improve the quality of the code.
A participant told us this: “When I’m in a good mood and I feel somehow positive,
the code I write seems to be very neat and clean. I mean, I can write code and analyze
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 errors and bugs.
The last factor we would like to report is mostly related to unhappiness, and it is
quite an important one. It is about mental unease and mental disorder. We created
this category to collect those consequences that threaten mental health. Participants
reported that unhappiness while developing software is a cause of anxiety (“These kinds
of situations make me feel panicky.”), stress (“[The] only reason [for] my failure [is] due
[to] 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 feeling
Chapter 10 happiness andtheproduCtivity ofsoftware engineers
121
depressed (“[…] feels like a black fog of depression surrounds you and the project.”).
In addition, we found mentions of feelings of being judged, frustration, and lack of
confidence in one’s ability.
What Does theFuture Hold?
In 1971, Gerald Weinberg’s book The psychology of programming [12] drew attention to
the fact that software development is a human endeavor, and the humans doing it—the
developers—are individuals with feelings. To this day, we still have more to understand
about the human factor in software development. Software development productivity
is still often managed as if it were about delivering code on an assembly line (see, e.g.,
Chapter 11). On the other hand, many companies do understand the importance of
happy developers, invest in their well-being, and consider it to be worthwhile.
As we have shown, the link between happiness and productivity in software
development is real. It is possible to quantify the happiness of software developers, and
there are distinct patterns in the causes and consequences of their happiness.
What if we could include happiness as a factor in software development productivity
management? In the future, an increasing number of people will work with digital
products and services and perform tasks that are, in effect, software development. It
would be worth investing in their happiness. It is important that we learn more about
the relationship between well-being and software development performance. Rigorous
research and educating practitioners on the research results are keys to improve the
field. Besides sharp technical skills, we would like to give future software developers an
understanding of the social and psychological factors that influence their own work.
Further Reading
In this chapter, we reported on several studies on the happiness of software engineers.
Some of these studies [1, 2, 3, 5, 11] were self-contained and independent. Other studies
[4, 6] are part of an ongoing project that we described in the section “Scientific Grounds
of Happy and Productive Developers.
At the time of writing of this chapter, we still have to uncover all the categories,
including those about what makes developers happy. We invite readers to inspect our
open science repository [10], where we add new papers and results as we uncover them.
The repository contains the entire taxonomy of what makes developers unhappy.
Chapter 10 happiness andtheproduCtivity ofsoftware engineers
122
Key Ideas
Here are the key ideas from this chapter:
Science says the industry should strive for happy developers.
e overall happiness of software developers is slightly positive. Yet,
many are still unhappy.
e causes of unhappiness among software engineers are numerous
and complex.
Happiness and unhappiness bring a plethora of benets and
detriments to software development processes, people, and products.
References
[1] Graziotin, D., Wang, X., and Abrahamsson, P. 2014. Happy software
developers solve problems better: psychological measurements
in empirical software engineering. PeerJ. 2, e289. DOI=10.7717/
peerj.289. Available: https://doi.org/10.7717/peerj.289.
[2] Graziotin, D., Wang, X., and Abrahamsson, P. 2015. Do feelings
matter? On the correlation of aects and the self-assessed
productivity in software engineering. Journal of Software:
Evolution and Process. 27, 7, 467–487. DOI=10.1002/smr.1673.
Available: https://arxiv.org/abs/1408.1293.
[3] Graziotin, D., Wang, X., and Abrahamsson, P. 2015. How do you
feel, developer? An explanatory theory of the impact of aects
on programming performance. PeerJ Computer Science. 1, e18.
DOI=10.7717/peerj-cs.18. Available: https://doi.org/10.7717/
peerj-cs.18.
[4] Graziotin, D., Fagerholm, F., Wang, X., and Abrahamsson, P. 2017.
On the Unhappiness of Software Developers. 21st International
Conference on Evaluation and Assessment in Software Engineering.
21st International Conference on Evaluation and Assessment in
Software Engineering, 324–333. DOI=10.1145/3084226.3084242.
Available: https://arxiv.org/abs/1703.04993.
Chapter 10 happiness andtheproduCtivity ofsoftware engineers
123
[5] Graziotin, D., Wang, X., and Abrahamsson, P. 2014. Software
Developers, Moods, Emotions, and Performance. IEEE Software. 31,
4, 24–27. DOI=10.1109/MS.2014.94. Available: https://arxiv.org/
abs/1405.4422.
[6] Graziotin, D., Fagerholm, F., Wang, X., & Abrahamsson, P.
(2018). What happens when software developers are (un)happy.
Journal of Systems and Software, 140, 32-47. DOI=10.1016/j.
jss.2018.02.041. Available: https://doi.org/10.1016/j.
jss.2018.02.041
[7] Zelenski, J.M., Murphy, S.A., and Jenkins, D.A. 2008. e Happy-
Productive Worker esis Revisited. Journal of Happiness Studies.
9, 4, 521–537. DOI=10.1007/s10902-008-9087-4.
[8] Diener, E., Wirtz, D., Tov, W., Kim-Prieto, C., Choi, D.-w., Oishi, S.,
and Biswas- Diener, R. 2010. New Well-being Measures: Short Scales
to Assess Flourishing and Positive and Negative Feelings. Social
Indicators Research. 97, 2, 143-156. DOI=10.1007/s11205-009-9493-y.
[9] Bradley, M.M. and Lang, P.J. 1994. Measuring emotion: e
self-assessment manikin and the semantic dierential. Journal
of Behavior erapy and Experimental Psychiatry. 25, 1, 49-59.
DOI=10.1016/0005-7916(94)90063-9.
[10] Graziotin, D., Fagerholm, F., Wang, X., and Abrahamsson, P. 2017.
Online appendix: the happiness of software developers. Figshare.
Available: https://doi.org/10.6084/m9.figshare.c.3355707.
[11] Fagerholm, F., Ikonen, M., Kettunen, P., Münch, J., Roto, V.,
Abrahamsson, P. 2015. Performance Alignment Work: How
software developers experience the continuous adaptation of team
performance in Lean and Agile environments. Information and
Software Technology. 64, 132–147. DOI=10.1016/j.infsof.2015.01.010.
[12] Weinberg, G.M. (1971). Psychology of Computer Programming
(1 ed.). NewYork, NY, USA: Van Nostrand Reinhold Company.
[13] Piper, B.J., Mueller, S.T., Talebzadeh, S., Ki, M.J. 2016. Evaluation of the
validity of the Psychology Experiment Building Language tests of vigilance,
auditory memory, and decision making. PeerJ. 4, e1772. DOI=10.7717/
peerj.1772. Available: https://doi.org/10.7717/peerj.1772.
Chapter 10 happiness andtheproduCtivity ofsoftware engineers
124
[14] Piper, B.J., Mueller, S.T., Geerken, A.R, Dixon, K.L., Kroliczak,
G., Olsen, R.H. J., Miller, J.K. 2015. Reliability and validity of
neurobehavioral function on the Psychology Experimental Building
Language test battery in young adults. PeerJ. 3, e1460. DOI=10.7717/
peerj.1460. Available: https://doi.org/10.7717/peerj.1460.
[15] 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, 1, 43–57.
DOI=10.1016/j.obhdp.2009.11.009.
[16] Graziotin, Daniel; Fagerholm, Fabian; Wang, Xiaofeng;
Abrahamsson, Pekka (2017): Slides for the consequences
of unhappiness while developing software. https://doi.
org/10.6084/m9.figshare.4869038.v3.
Open Access This chapter is licensed under the terms of the Creative
Commons Attribution-NonCommercial-NoDerivatives 4.0 International
License (http://creativecommons.org/licenses/by-nc-nd/4.0/), which permits any
noncommercial use, sharing, distribution and reproduction in any medium or format,
as long as you give appropriate credit to the original author(s) and the source, provide a
link to the Creative Commons license and indicate if you modified the licensed material.
You do not have permission under this license to share adapted material derived from
this chapter or parts of it.
The images or other third party material in this chapter are included in the chapter’s
Creative Commons license, unless indicated otherwise in a credit line to the material. If
material is not included in the chapter’s Creative Commons license and your intended
use is not permitted by statutory regulation or exceeds the permitted use, you will need
to obtain permission directly from the copyright holder.
Chapter 10 happiness andtheproduCtivity ofsoftware engineers
ResearchGate has not been able to resolve any citations for this publication.
Article
Full-text available
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.
Article
Full-text available
Background. The Psychology Experimental Building Language (PEBL) http://pebl.sourceforge.net/ test battery is a popular application for neurobehavioral investigations. This study evaluated the correspondence between the PEBL and the non-PEBL versions of four executive function tests. Methods. In one cohort, young-adults (N = 44) completed both the Conner’s Continuous Performance Test (CCPT) and the PEBL CPT (PCPT) with the order counter-balanced. In a second cohort, participants (N = 47) completed a non-computerized (Wechsler) and a computerized (PEBL) Digit Span (WDS or PDS) both Forward and Backward. Participants also completed the Psychological Assessment Resources or the PEBL versions of the Iowa Gambling Task (PARIGT or PEBLIGT). Results. The between test correlations were moderately high (reaction time r = 0.78, omission errors r = 0.65, commission errors r = 0.66) on the CPT. DS Forward was significantly greater than DS Backward independent of the test modality. The total WDS score was moderately correlated with the PDS (r = 0.56). The PARIGT and the PEBLIGTs showed a very similar pattern for response times across blocks, development of preference for Advantageous over Disadvantageous Decks, and Deck selections. However, the amount of money earned (score – loan) was significantly higher in the PEBLIGT during the last Block. Conclusions. These findings are broadly supportive of the criterion validity of the PEBL measures of sustained attention, short-term memory, and decision making. Select differences between workalike versions of the same test highlight how detailed aspects of implementation may have more important consequences for computerized testing than has been previously acknowledged.
Article
Full-text available
Background. The Psychology Experimental Building Language (PEBL) test battery (http://pebl.sourceforge.net/) is a popular application for neurobehavioral investigations. This study evaluated the correspondence between the PEBL and the non-PEBL versions of four executive function tests. Methods. In one cohort, young-adults (N = 44) completed both the Conner’s Continuous Performance Test (CCPT) and the PEBL CPT (PCPT) with the order counter-balanced. In a second cohort, participants (N = 47) completed a non-computerized (Wechsler) and a computerized (PEBL) Digit Span (WDS or PDS) both Forward and Backward. Participants also completed the Psychological Assessment Resources or the PEBL versions of the Iowa Gambling Task (PARIGT or PEBLIGT). Results. The between-test correlations were moderately high (reaction time r = 0.78, omission errors r = 0.65, commission errors r = 0.66) on the CPT. DS Forward was significantly greater than DS Backward on the WDS (p < .0005) and the PDS (p < .0005). The total WDS score was moderately correlated with the PDS (r = 0.56). The PARIGT and the PEBLIGTs showed a very similar pattern for response times across blocks, development of preference for Advantageous over Disadvantageous Decks, and Deck selections. However, the amount of money earned (score–loan) was significantly higher in the PEBLIGT during the last Block. Conclusions. These findings are broadly supportive of the criterion validity of the PEBL measures of sustained attention, short-term memory, and decision making. Select differences between workalike versions of the same test highlight how detailed aspects of implementation may have more important consequences for computerized testing than has been previously acknowledged.
Article
Full-text available
Background. The Psychology Experiment Building Language (PEBL) software consists of over one-hundred computerized tests based on classic and novel cognitive neuropsychology and behavioral neurology measures. Although the PEBL tests are becoming more widely utilized, there is currently very limited information about the psychometric properties of these measures. Methods. Study I examined inter-relationships among nine PEBL tests including indices of motor-function (Pursuit Rotor and Dexterity), attention (Test of Attentional Vigilance and Time-Wall), working memory (Digit Span Forward), and executive-function (PEBL Trail Making Test, Berg/Wisconsin Card Sorting Test, Iowa Gambling Test, and Mental Rotation) in a normative sample (N = 189, ages 18–22). Study II evaluated test–retest reliability with a two-week interest interval between administrations in a separate sample (N = 79, ages 18–22). Results. Moderate intra-test, but low inter-test, correlations were observed and ceiling/floor effects were uncommon. Sex differences were identified on the Pursuit Rotor (Cohen’s d = 0.89) and Mental Rotation (d = 0.31) tests. The correlation between the test and retest was high for tests of motor learning (Pursuit Rotor time on target r = .86) and attention (Test of Attentional Vigilance response time r = .79), intermediate for memory (digit span r = .63) but lower for the executive function indices (Wisconsin/Berg Card Sorting Test perseverative errors = .45, Tower of London moves = .15). Significant practice effects were identified on several indices of executive function. Conclusions. These results are broadly supportive of the reliability and validity of individual PEBL tests in this sample. These findings indicate that the freely downloadable, open-source PEBL battery (http://pebl.sourceforge.net) is a versatile research tool to study individual differences in neurocognitive performance.
Article
Full-text available
Affects---emotions and moods---have an impact on cognitive processing activities and the working performance of individuals. Development tasks are undertaken through cognitive processing activities. Yet, software engineering research lacks theory on affects in software development. In this paper, we report an interpretive study aimed to broaden our understanding of the psychology of programming in terms of affects perception and their impact while programming. We conducted a qualitative interpretive study based on face-to-face, open-ended interviews, in-field observations, and e-mail exchanges, which enabled us to construct a novel explanatory theory of the impact of affects on development performance. The theory is explicated using an established taxonomy framework. The proposed theory builds upon the concepts of events, affects, attractors, focus, goal, and performance. Theoretical and practical implications are given.
Article
Full-text available
For more than thirty years, it has been claimed that a way to improve software developers' productivity and software quality is to focus on people and to provide incentives to make developers satisfied and happy. This claim has rarely been verified in software engineering research, which faces an additional challenge in comparison to more traditional engineering fields: software development is an intellectual activity and is dominated by often-neglected human factors (called human aspects in software engineering research). Among the many skills required for software development, developers must possess high analytical problem-solving skills and creativity for the software construction process. According to psychology research, affective states-emotions and moods-deeply influence the cognitive processing abilities and performance of workers, including creativity and analytical problem solving. Nonetheless, little research has investigated the correlation between the affective states, creativity, and analytical problem-solving performance of programmers. This article echoes the call to employ psychological measurements in software engineering research. We report a study with 42 participants to investigate the relationship between the affective states, creativity, and analytical problem-solving skills of software developers. The results offer support for the claim that happy developers are indeed better problem solvers in terms of their analytical abilities. The following contributions are made by this study: (1) providing a better understanding of the impact of affective states on the creativity and analytical problem-solving capacities of developers, (2) introducing and validating psychological measurements, theories, and concepts of affective states, creativity, and analytical-problem-solving skills in empirical software engineering, and (3) raising the need for studying the human factors of software engineering by employing a multidisciplinary viewpoint.
Article
We examine the intra-individual relationships between state mood and the primary components of the individual-level criterion space (task performance, organizational citizenship behavior, and work withdrawal) as they vary within the stream of work. Using experience-sampling methods, 67 individuals in a call center responded to surveys on palmtop computers at random intervals 4–5 times each day for 3 weeks (total N = 2329). These data were matched to objective task performance obtained from organizational call records (total N = 1191). Within-persons, periods of positive mood were associated with periods of improved task performance (as evidenced by shorter call time) and engaging in work withdrawal. Trait meta-mood moderated these relationships. Specifically, individuals who attended to their moods had a stronger relationship between mood and speed of task performance (call time) and individuals able to repair their mood cognitively evidenced a weaker relationship between mood and withdrawal. Implications and the use of within-persons designs are discussed.
Do feelings matter? On the correlation of affects and the self-assessed productivity in software engineering
  • D Graziotin
  • X Wang
Graziotin, D., Wang, X., and Abrahamsson, P. 2015. Do feelings matter? On the correlation of affects and the self-assessed productivity in software engineering. Journal of Software: Evolution and Process. 27, 7, 467-487. DOI=10.1002/smr.1673. Available: https://arxiv.org/abs/1408.1293.
  • D Graziotin
  • F Fagerholm
  • X Wang
Graziotin, D., Fagerholm, F., Wang, X., and Abrahamsson, P. 2017. On the Unhappiness of Software Developers. 21st International Conference on Evaluation and Assessment in Software Engineering. 21st International Conference on Evaluation and Assessment in Software Engineering, 324-333. DOI=10.1145/3084226.3084242. Available: https://arxiv.org/abs/1703.04993.
Software Developers, Moods, Emotions, and Performance
  • D Graziotin
  • X Wang
Graziotin, D., Wang, X., and Abrahamsson, P. 2014. Software Developers, Moods, Emotions, and Performance. IEEE Software. 31, 4, 24-27. DOI=10.1109/MS.2014.94. Available: https://arxiv.org/abs/1405.4422.