Unhappiness and the Productivity of Software Engineers: A review of research
Since the ancient times, philosophers such as Aristotle and Plato pondered the ‘big’ questions about
happiness; what is happiness, how do we live a happy life, and why is it important that we do?
In recent years, many companies from start-ups to conglomerates have placed importance on
answering these questions to ensure they get the most out of their employees, after all we so often
“Happy employees are productive employees!”
With the rise of software start-ups, the digitization of existing businesses and the overwhelming
reliance on tech, there is arguably no workforce where understanding ways to foster happiness is
more important than within Software Development teams. But this is a lot more complicated to achieve than employers might be willing to consider. It is more than offering workers perks such as free meals, playrooms, sleep pods, sports facilities, and such like. To better understand how to make employers happy, it might be best to get to the bottom of what is making them ‘unhappy’ in the workplace and go about limiting these negative experiences.
Graziotin et al., (2017) in their research and subsequent paper On the Unhappiness of Software Developers set out to explore just that. Their sample consisted of 1318 software developers in different sized companies around the world (88 countries). First, they assessed the underlying happiness of their sample of software developers using the Scale of Positive and Negative Experience (SPANE-B), where -24 is extremely unhappy and +24 is extremely happy, and 0 is neutral. The participants had an average score of 9.05 showing that most
software developers are ‘moderately happy’. However, they commented: “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.”
Then they analysed the most significant causes of developer unhappiness, which were divided up into 2 main categories;
1) factors which relate to their ‘own being’ (e.g. resulting from their own state of mind or behaviours), and
2) factors which relate to external causes
Through both quantitative and qualitative research questions, they discovered the top 10 causes of unhappiness amongst software developers.
Most causes of unhappiness came from issues with the technical factors relating to the artifact (software product, tests, requirements and design document, architecture etc.) and the process. This emphasises the importance of establishing a company’s strategic architecture, DevOps practices and workforce coordination.
The two most frequent causes of unhappiness are ‘being stuck in problem solving’ and ‘time pressure’. It is widely recognised that software developers are ‘problem-solvers’ at heart, so it seems obvious to learn that they feel bad when they are not able to come up with a solution and are under time pressure to do so. This is where coaches and managers need to intervene to reduce the detrimental psychological effects that these factors can cause by creating a support framework around these employees.
The third most common cause of unhappiness is working with bad code that could have been avoided to begin with and is reportedly, often due to management making bad decisions to save time and effort. Understandably, this is frustrating for developers as it means they need to spend their time ‘fixing’ instead of ‘developing’. Furthermore, colleagues, team leaders or customers who make developers feel inadequate with their work or force them to do repetitive mundane tasks are a common source of unhappiness. Management can alleviate these negative consequences by rotating tasks, having better decision- making processes, and really listening to developers.
Factors related to information needs in terms of software quality and software construction are strong contributors to unhappiness among software developers. Software developer tools, although designed to assist, may overload developers with information. There is a strong requirement for tools and methods that make communication and knowledge sharing and management easier by storing, retrieving, and understanding information in all stages of the software development life cycle.
So what does all this mean for productivity?
Both internal and external factors can have enormous detrimental consequences on the productivity of an individual developer and the impact on the project overall.
Developers from this sample reported that having negative experiences or feeling unhappy can have a noticeable effect on their productivity. The main areas which this was mentioned are:-
1. Cognitive Performance. Being happy helps us to efficiently process information in our brain and focus on tasks. When we are unhappy we are focussing on the source of our unhappiness rather than the task at hand, causes mental fatigue and leads to burnout.
2. Flow. Unhappiness causes interruptions in developers’ flow, resulting adverse effects on the process. When happy developers ‘enter a state of sustained flow’.
3. Motivation and Withdrawal. Unhappiness leads to low motivation for developing software and finding solutions, and results in employees withdrawing from daily work tasks.
One participant summarised the impact of being happy on their work:- “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.”
Undoubtedly, being happy or unhappy influences not only the drive and productivity of software developers but also the quality of their work.
It is no easy feat, but it is clear from the research conducted by Graziotin et al., (2017) that by asking and listening to developers’ reasons for unhappiness in the workplace, and going about eliminating these negative experiences, companies can better understand how to make their employees happier…and more productive.
As Frederick Brooks summarised eloquently in his 1986 paper “No Silver Bullet – Essence and Accident in Software Engineering”:
“There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement with a decade in productivity, in reliability, in simplicity.”