Consequences of Unhappiness While Developing Software

TL;DR

This study explores the negative impacts of unhappiness on software developers, revealing 49 consequences across mental health, development process, and artifacts, and provides a classification scheme to guide future research and practice.

Contribution

It uncovers and classifies the consequences of unhappiness among developers, expanding understanding beyond productivity and quality to include mental well-being and process impacts.

Findings

Unhappiness affects mental well-being of developers.

Unhappiness impacts the software development process.

Unhappiness influences the quality of software artifacts.

Abstract

The growing literature on affect among software developers mostly reports on the linkage between happiness, software quality, and developer productivity. Understanding the positive side of happiness -- positive emotions and moods -- is an attractive and important endeavor. Scholars in industrial and organizational psychology have suggested that also studying the negative side -- 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, and is mainly expressed in terms of development productivity and software quality. In this paper, we attempt to uncover the experienced consequences of unhappiness among software developers. Using qualitative data analysis of the responses given by 181 questionnaire participants, we identified 49 consequences of unhappiness while doing software development. 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 damaging effects of unhappiness and for fostering happiness on the job.

Full text

I Introduction

Software companies often gladly promote the idea of flourishing happiness among developers, knowingly or accidentally attempting to enact the happy-productive worker thesis [1]. The happiness of all stakeholders involved in software development is an essential element of company success [2]. Recent research within the scope of behavioral software engineering [3] has highlighted the relationship between software developer happiness and work-related constructs such as performance and productivity [4, 5, 6, 7, 8, 9], quality [10, 11], and the social interactions between developers [12]. Most of the studies to date have investigated the positive side of happiness.

While happiness, for the individual, is inherently subjective, research shows that it can be studied objectively. Objective happiness can be construed as the difference between experienced positive affect and experienced negative affect [13, 14]. Thus, maximizing happiness may be achieved by either maximizing positive experiences or minimizing negative experiences (or both). Focusing on the negative may already be intuitive to many developers.

It is a common occurrence that developers share horror stories about their working experience [15]. Managers in the software profession would benefit from greater understanding of the nature and dynamics of unhappiness among developers, and they could take action to prevent dysfunctional responses among employees [16]. Further understanding of the benefits of limiting negative experiences on the job in general has been called for [13].

We aim to broaden the understanding of the unhappiness of software developers, and are conducting a series of studies using a large-scale quantitative and qualitative survey of software developers. In those studies, we assess the happiness in the developer population, the causes of (un)happiness, and what the consequences of those experiences are. The study we are describing in the present paper is the first of the series111We are offering a preview of the results of the present study in an ICSE’17 poster as well [17]..

In the present article, we focus on the consequences of unhappiness, and investigate the following research question which is based on the existing literature:

RQ: What are the experienced consequences of unhappiness among software developers while developing software?

We report 49 consequences of unhappiness that we identified. The consequences concern developers themselves in the form of cognitive and behavioral changes, and external outcomes related to the software development process and artifacts.

II Related Work

From a hedonistic viewpoint, happiness is a sequence of experiential episodes [18] and being happy (unhappy) is associated with frequent experiences of positive (negative) affect [19].222Alternative views of happiness exist, e.g. Aristoteles’ eudaimonia: a person is happy because (s)he conducts a satisfactory life full of quality [20]. A review of affect theories is given in [21] and the role of the centrality of affect and happiness is discussed in [4]. A considerable increase in the interest of studying affect and happiness among software developers is visible over the last five years, although the research is in its infancy; many theoretical and methodological issues remain in software engineering research, as illustrated by Graziotin et al. [21, 22] and by Novielli et al. [12].

Several studies have attempted to elucidate the complex relationship between happiness (and more generally, affect) and performance in the context of software development. In a study of the affect associated with eliciting requirements, investigating 65 user requirements from two projects, high activation and low pleasure levels were shown to be predictors of high versioning requirements [23]. Pleasure increased over time with each new version, while activation decreased.

Theory-building is an important part of software engineering research, and theories regarding affect can inform further empirical studies. One such theory is an explanatory process theory of the impact of affect on development performance [4]. The theory was formed by qualitative analysis of interview data, communications, and observations of two software developers in the same project. The concept of attractors – affective experiences that earn importance and priority to a developer’s cognitive system – was theorized to have the biggest impact on development performance.

Correlational experiments have found a positive relationship between happiness and positive emotions arising from a development task [5, 6], and between problem-solving performance and development task productivity [8]. Affect has also been shown to impact debugging performance: in a controlled experiment where participants were asked to write a trace of algorithm execution, induced high pleasure and activation affect were found to be associated with high debugging performance [10].

Further evidence for the link that developers experience between emotion and performance is provided in a survey with 49 developers, assessing emotions they perceived to influence their own productivity [24]. Positive affective states were perceived to be those that enhance development productivity. The negative affect most prevalently perceived was frustration, which was also the one perceived to deteriorate productivity the most.

In all studies investigating the happiness of developers in different forms and its impact on performance, the findings point to a positive relationship. The findings are similar when it comes to software quality. A series of studies using software repository mining found links between affect, emotions, and politeness, and software quality [9, 11, 25]. Happiness in terms of frequent positive affect and positive emotions was found to be associated with shorter issue fixing time [9]. The level of arousal, which, when high, is associated with anxiety and burnout, was found the be associated with issue priority [25]. Politeness in requests for resolving issues was correlated with lower resolution time [11].

III Method

The present study is the first in a series of inquiries that we conducted on data from a large-scale survey of developers. The overall research project employs a mixed research method, with elements of both quantitative and qualitative research [26]. The present study, however, is purely qualitative.

III-1 Sampling Strategy

We used GitHub as an avenue for reaching software developers that would represent the population of developers well enough, following several previous studies (e.g. [27]). GitHub has more than 30 million visitors each month [28] and is, as far as we can tell, the largest social coding community in the world. Software developers using GitHub work on a wide variety of projects, ranging from open source to proprietary software and from solo work to work done in companies and communities.

We extracted a set of developer contacts from the GitHub Archive, which stores public events occurring in GitHub. We retrieved event data for a period of six months, and extracted email addresses, given names, company names, developer locations, and the repository name associated with each event.

III-2 Survey Design

We designed a survey consisting of (1) questions regarding demographics, (2) one question with the Scale of Positive and Negative Experience (SPANE [19]) with 12 items assessing happiness, and (3) two open-ended questions asking for experienced causes and consequences of positive and negative affect when developing software. The questionnaire is described in an online appendix [29]. We piloted the questionnaire thrice, allowing us to estimate and improve response rates by refining the questions and invitation email. No data from the pilots were retained in the final data set and pilot participants did not participate in the final round. The present article covers the results related to the open-ended questions regarding the consequences of negative affect (thus, unhappiness) while developing software.

III-3 Analysis

We qualitatively analyzed the cleaned data for the open-ended questions. In order to answer the RQ of this paper, we used the responses for the question on consequences. We developed a coding strategy, applying open coding, axial coding, and selective coding as defined by Corbin and Strauss’ Grounded Theory [30] as follows333For a review and guidelines of Grounded Theory in software engineering research, see [31]. The first three authors each coded the same set of 50 responses using a line-by-line strategy. We then compared the coding structure and strategy and reached an agreement, i.e., a shared axial coding scheme. We took the individual developer as the starting point and unit of observation and analysis, and based the construction of theoretical categories on a model [32] of constructs that are internal or external to the developer. The internal category concerns the developer’s own being, while the external category contains artifacts, processes, and people as subcategories. We then divided the data evenly among the first three researchers and proceeded to open code them. We monitored our progress and further discussed the coding scheme and strategy in weekly meetings. We finally merged the codes and conducted a last round of selective coding. An example illustrating the coding process is available online [29]. All analysis was done using NVIVO 11.

IV Results

In this section, we summarize the results of our investigation. We first show descriptive statistics describing the demographics of the participants. We then proceed to the qualitative data related to our RQ.

IV-A Descriptive Statistics

We obtained $181$ valid and complete—that is, after data cleaning—responses related to our RQ, which resulted in $172$ male participants (95%) and 8 female (4%). The remaining participant declared their gender as other / prefer not to disclose. The mean for the year of birth was 1984 (standard deviation (sd)=8.27), while the median was 1986. A wide range of nationalities was represented, with 45 countries. 141 (78%) participants were professional software developers, 7% were students, and 13% were in other roles (such as manager, CEO, CTO, and academic researcher). The remaining participants were non-employed and not students. The participants declared a mean of 8.22 years (sd=7.83) software development working experience, with a median of 5 years.

What are the Experienced Consequences of Unhappiness Among Software Developers While Developing Software?

We now provide a summary of the elicited consequences of unhappiness while developing software. We identified 254 codes related to the consequences of unhappiness, which resulted in 49 consequences, divided into 16 categories and sub-categories. Because of space limitations, we report here the most frequent codes. The entire dataset is available as archived open data [29]. We found support for Curtis et al. [32] internal category, which we label developer’s own being (112 references), and the external categories process (106) and artifact (36).

IV-B Internal Consequences—Developer’s Own Being

The developer’s own being-related factors do not demonstrate a clear structure. This to some extent reflects the versatile states of mind of developers and the feelings they could have while they develop software.

The most significant consequences of unhappiness for the developers’ own being are: low cognitive performance, mental unease or disorder, and low motivation.

Low cognitive performance is a category to group all those consequences related to low mental performance, such as low focus: “[…] the negative feelings lead to not thinking things through as clearly as I would have if the feeling of frustration was not present”; cognitive skills dropping off: “My software dev skills dropped off as I became more and more frustrated until I eventually closed it off and came back the next day to work on it”; and general mental fatigue: “Getting frustrated and sloppy”.

The mental unease or disorder category collects all those consequences that threaten mental health444In this study, we report what the participants stated, but we remind readers that only trained psychologists and psychiatrists should treat or diagnose mental disorders.. The participants reported that unhappiness while developing software is a cause of, in order of frequency, stress and burnout: “[…] only reason of my failure due of burnout”; anxiety: “These kinds of situations make me feel panicky”; low self-esteem: “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. Participants mentioned depression as in feeling depressed, e.g., “feels like a black fog of depression surrounds you and the project” or “I get depressed”.

Low motivation is also an important consequence of unhappiness for software developers. Motivation is a set of psychological processes that cause the mental activation, direction, and persistence of voluntary actions that are goal directed [33]. Motivation has been the subject of study in software engineering literature (e.g, [34]), and we reported that affective experiences are related to motivation even though they are not the same construct [22]. The participants were clear in stating that unhappiness leads to low motivation for developing software, e.g, “[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. […]”, or “Also, I’m working at a really slow pace […] because I’m just not as engaged with the work”.

Work withdrawal is a very destructive consequence of unhappiness, and it emerged often among the responses. Work withdrawal is a family of behaviors that is defined as employees’ attempts to remove themselves, either temporarily or permanently, from quotidian work tasks [35]. The gravity of this consequence ranged from switching to another task, e.g, “[…] you spend like 2 hours investigating on Google for a similar issue and how it was resolved, you find nothing, desperation kicks in. It clouds your mind and need to do other things to clear it”, to considering quitting developing software, “I really start to doubt myself and question whether I’m fit to be a software developer in the first place”, or even, “I left the company”.

IV-C *External Consequences—Process *

The category of process collects those unhappiness consequences that are related to a software development process, endeavor, or set of practices that is not explicitly tied up to an artifact (see Section IV-D).

Low productivity is a category for grouping all consequences of unhappiness related to performance and productivity losses555See [4] and [7] for our stance on a definition of productivity and performance in software engineering.. The codes within this category were ranging from very simple and clear “productivity drops”, “[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”, “[…], and [the negative experience] slowed my progress because of the negative feeling toward the feature”.

Unhappiness was reported to be causing delay in executing process activities: “In both cases [negative experiences] the emotional toll on me caused delays to the project”. Unhappiness causes glitches to communication activities and a disorganized process: “Miscommunication and disorganization made it very difficult to meet deadlines”.

Developers declared that unhappiness caused them to deviate from the process or the agreed set of practices. Specifically, unhappiness makes developers compromise in terms of actions, in order to just get rid of the job: “In these instances my development tended towards immediate and quick ’ugly’ solutions”. Developers see their quality of the code compromised (Section IV-D) but also decide to take shortcuts when enacting a software process, compromising the quality of the process itself: “[…] can lead to working long hours and trying to find shortcuts. I’m sure this does not lead to the best solution, just a quick one”. The process adherence can suffer due to communication aspects, too: “my development was influenced by [negative affect] in that it caused me to tighten up communications and attempt to force resolution of the difficulties”.

Somehow related to the process deviation is the broken flow category. Unhappiness causes developers to interrupt the flow, as described by Csikszentmihalyi [36] and investigated by Müller and Fritz [8] as an attention state of progressing and concentration. As put by a participant, ‘things like that [of unhappiness] often cause long delays, or cause one getting out of the flow, making it difficult to pick up the work again where one has left off. ”. Unhappiness and the broken flow make developers stand up and “[…] make me quit and take a break”; the feeling of getting stuck is constant.

IV-D External Consequences—Artifact-oriented

The category of artifact-oriented consequences groups all those consequences that are directly related to a development product, e.g., software code, requirements, and to working with it. As expected by the foci of previous research, the most important consequence of unhappiness of software developers was low software quality.

Low code quality represents the consequences of unhappiness of developers that are related to deterioration of the artifacts’ quality. The 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”. Moreover, participants also felt that they could discharge quality practices, e.g, “so I cannot follow the standard design pattern”, as a way to cope with the negative experiences.

Discharging code could be seen as an extreme case of productivity and quality drop. We found some instances of participants who destroyed the task-related codebase, e.g, “I deleted the code that I was writing because I was a bit angry”, up to deleting entire projects: “I have deleted entire projects to start over with code that didn’t seem to be going in a wrong direction”.

V Discussion

In the quest for answering our RQ, we have shown that the unhappiness of developers negatively impacts several important software engineering outcomes. Productivity and performance are the aspects which suffer most from unhappy developers. When grouping low cognitive performance and process-related productivity codes, about 40% of the related in-text references deal with productivity and performance drops. Those results are in line with and support the related work in software engineering research [4, 5, 6, 8, 10, 24] which quantified the relationship or attempted to explain the link.

Our results show that unhappiness while programming may be source of several mental-related issues that are known to be of detrimental effect to the work environment. We found situations of mental unease, e.g., low self-esteem, high anxiety, burnout, and stress. Initial software engineering research on the latter two has started (e.g., [25]), but the related work in psychology is comprehensive and alarming in regards to how disruptive these issues are on well-being. Furthermore, our data has also shown mentions of possible mental disorders such as depressionfootnote 4.

Continuing with issues related to intellectual performance, unhappiness appears to also bring down motivation among developers, which is a critical force in software engineering activities [34]. Negative experiences and negative affect are also experienced to be causes of work withdrawal. Psychology research has recently started to investigate affect versus work withdrawal (e.g., [35]), but we are not aware of related software engineering research. Our data has shown that work withdrawal causes developers to distance themselves from the task that raises unhappiness up to the point of quitting jobs.

Finally, unhappiness makes developers take process-related shortcuts (i.e., to “cut corners”). These deviations are often mentioned to cause issues in terms of software quality. While a few studies have been conducted on the affect of developers and its impact on software quality (e.g, [10, 11, 37, 9]), we encourage future research on the matter.

V-A Limitations

We elicited the causes of unhappiness of software developers using qualitative data analysis techniques. Whether causality can be inferred from other than controlled experiments, e.g., eliciting experiences from introspection in the context of qualitative research, is a matter of debate [26, 38, 39]. However, several authors, e.g., [39], take the stance that qualitative data analysis is able to infer causality from experience of human participants, provided that there is a strong methodology for data gathering and analysis. In our case, we paid careful attention to Grounded Theory coding methodology [30] in order to strengthen the validity of our results. Furthermore, eliciting the consequences of unhappiness as experienced by developers themselves was our research goal. As the consequences come from first-hand reports, we argue that they accurately represent the respondents’ views. Our study does not show any general relationship between any specific consequences; only experienced consequences of unhappiness are claimed.

Our sample of software developers using GitHub is limited in size and with respect to representativeness of developers at large. Our dataset (see Section III-1) contains accounts with public activity during a six-month period. This may result in a bias as developers who prefer not to display their work in public would not be present in the data set; nor would developers whose work is done in companies’ internal systems. The six-month time period, however, is less of an issue as very inactive developers are of less interest to our study – but they may differ in terms of how they view consequences of unhappiness. Replication using different data sources and collection methods is needed to validate our results in these scenarios.

It might be the case that the “GitHub population of developers” is slightly younger than developers in general, but to our knowledge no supporting empirical evidence exists. GitHub is a reliable source for obtaining software engineering research data, as it allows replication of this study on the same or different populations. The GitHub community is large (30 million visitors per month [28]) and diverse in terms terms of team size, type of software, and several other characteristics. Our sample is similarly diverse and is balanced in terms of demographic characteristics, including participant role, age, experience, work type, company size, and students versus workers. One exception is gender: our sample is strongly unbalanced towards males. We believe, alas, that our sample is representative in terms of gender as well, as it is a known problem that software engineering roles are predominantly filled by males [37, 40, 41], although recent research is attempting to tackle the issue.

V-B Recommendations for Practitioners

We believe that our discovered consequences of unhappiness of developers should be of interest to practitioners working as managers, team leaders, but also team members. While the present paper contains the most prominent factors, we made the entire list available as archived open data [29]. Practitioners in leadership positions should attempt to foster happiness of software development teams by limiting their unhappiness. The benefits of fostering happiness among developers were empirically demonstrated in past research, and they especially highlight software development productivity and software quality boosts. With our results, we add that addressing unhappiness will limit the damage in terms of several factors at the individual, artifact, and process level. Moreover, previous research [4] has suggested that intervening on the affect of developers might have relatively low costs and astonishing benefits.

V-C Implications for Researchers

We believe that the results of the present work could be adopted as the basis of several research directions. Our study has the potential to open up new avenues in software engineering research based on the discovered factors (e.g., work withdrawal and affect of developers). Also, all the factors we have reported are the end part of an experienced causality chain with unhappiness as the antecedent. Future studies should attempt to seek a quantification of the chain.

VI Conclusion

In this paper, we presented the results of an analysis of the experienced consequences of unhappiness among software developers while developing software. The complete results are archived and available as open data [29]. The consequences are grouped into the main categories of internal – developer’s own being – and external – process and artifact. The highest impact is experienced to be on programming productivity as expressed by cognitive performance, including creativity and flow, and process-related performance. We found several instances of job-related adverse effects and even indications of mental disorders: work withdrawal, stress, anxiety, burnout, and depressionfootnote 4.

Our recommendation to practitioners, including managers and team leaders, is to utilize our list of consequences and the explanations offered by the present paper to start their quest for enhancing the working conditions of software developers. The consequences, in particular, offer interesting angles which managers should reflect on and look out for in their workforce.

We believe that our study results are of immediate application in future academic work. The results set theoretical foundations for causality studies and inspiration for novel research activities in software engineering.

The present study enforces the stance that many aspects of software engineering research require approaches from the behavioral and social sciences; we believe there is a need in future academic discussions to reflect on how software engineering research can be characterized in such terms. Developers are prone to share work-related horror stories on a daily basis, and we believe that their job conditions are often overlooked. With our past and present research activities, we hope we can contribute towards a higher well-being of software engineers, while enhancing the amount and quality of their job outputs.

Acknowledgment

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.