A New Approach To Predict Burnout Risk for Software Developers

Summary

• Burnout symptoms are often a result of suboptimal procedures and working conditions. They are signs of a serious and protracted illness.
• Especially, burnout of software developers is more widespread than one might suspect. It hits companies via increased employee turnover, reduced team productivity and above-average sick leave just as hard as the affected employees. 
• Amongst many other reasons, “meaningless” work, frequently changing priorities, unrealistic goals, deadlines, and overwork are disproportionately often named as causes.
• Early indicators for these most important burnout causes can be identified from the work on the software code with the DETANGLE Analysis Suite.
• With these analysis results, project leaders/-management have information at hand to identify health-threatening working conditions of their developers at an early stage and can initiate countermeasures timely.   
• By regularly applying these analyses, additional information regarding the trend of the relevant key metrics will become available. Over time it becomes increasingly easy to narrow down the causes of a developer’s burnout and to avoid it before the individual and as a consequence, the organisation is seriously impacted.

Why are software developers so often exposed to burnout symptoms?

Burnout is a serious and protracted illness.  There is still no clear definition and diagnosis for it. Often, it is confused with depression. 

A helpful description can be found, for example, at Burnout Prevention for Software Developers [1]:

“Burnout is one of those things you don’t notice until you already have it. But people with symptoms of burnout are people who are generally always working, always on – they feel like they can never take a break or have downtime.”

– Abby Kearns, Cloud Foundry

The consequences of burnout are severe for the individual developer, the team and the company. The following list of some symptoms are consistently cited How Not to Burnout: Guide for Software Developers [2]:

• “Becoming cynical or overly critical at work”
• “Lack of energy and concentration with no evident cause”
• “Constant fatigue”
• “Procrastinating on tasks that you used to do enthusiastically”
• “Feelings of dread, apathy, and being out of control”
• “Lowered productivity”
• “Minor to major anxiety”
• “Outbursts of anger”

One could argue that burnout happens in every profession. But software engineering is particularly predestined for it. And there is a reason for that.

‘Software engineering has no limits. Work is not defined by a set number of hours per day, but by optimistic and sometimes arbitrary management deadlines. As one senior tech CEO told me, “I knew there was no chance of meeting my deadline, but I just wanted to get the engineering team to work faster.” In addition, understaffing of project teams is  common because recruiting developers is difficult – and expensive.’ [3]

The publication  Beware Burnout [3] lists the following software development-specific reasons for an increased probability to get a burnout:

1. “Unclear or rapidly changing direction” (A), 
2. “Bus factor is low” (B), 
3. “Programming is isolating” (D),
4. “Draining work of maintenance” (C), 
5. “Impatient or ungrateful users” (in the case of open source development)
6. “Coding for others” 

Other publications such as 7 Reasons why programmers burn out [4] and Only You Can Prevent Tech Burnout [5] list quite similar and further reasons. The various reasons the different authors find causal for increased susceptibility for burnout can be consolidated into four clusters:

Table 1: Work condition categories and their influence on burnout of software developers

Of course, it also depends on very individual circumstances whether the employee suffers from burnout. But since it is a very serious and long-lasting disease, it is even more important to measure the known causes and their impact on the individual developer as early as possible and to implement prevention concepts. In the following sections, we show that many causes of burnout can be extracted by investigating the work on the software code with our DETANGLE® analysis software.

Early indicators of burnout are measurable with DETANGLE®

The first step in burnout prevention is to identify indicators that are known or reasonably suspected to be associated with an increased susceptibility for burnout as shown in table 1. For the category clusters A, B and C, we record the following parameters per developer over time with DETANGLE®:

1. What is the developer’s share of workload of system maintenance vs. feature development?
2. How many features/user stories does a developer work on simultaneously and what is their effort distribution?
3. How many different source code directories is the developer working on simultaneously? 
4. How many different programming languages is the developer working with?
5. Does a developer pose a project risk over a longer period of time due to his relevant and special knowledge, and is she/he aware of it (bus factor)?

The analysis of these data gives clear insights about working circumstances that are known to cause an overproportional amount of employees burdened with burnout syndrome. For example, the higher the individual’s maintenance effort, the lower the proportion of real value-adding work that usually is seen as a satisfying activity (C). The higher the number of features/user stories and the higher the number of source code directories or programming languages, the lower the developer’s focus (A), whereas the Bus Factor also indirectly reflects his workload (B).

Figure 1: Bus Factor Trend over time

The figure shows the Bus Factor, i.e. the number of key developers for the Django open-source project. It can be seen that their number has increased from 4 to 7 developers from 2019 to 2020, and about 12% of the developers are considered mission-critical and contribute to the Bus Factor. The loss of one of these developers is always a project risk. Since these key developers also usually have the highest workload and responsibility, they are particularly at risk for burnout. Thus, the Bus Factor is also an early indicator of the number of employees at risk for burnout. If a developer is recorded as a Bus Factor for a longer time, project management should try to rebalance his load and reduce his/her high level of continuous high importance for the project(s). 

We have already addressed the causes of category D from the previous section (problem of poor cooperation) in several blogs. Under Software Due Diligence – Developers and their Cooperation in Focus [6] and (Collective) Code Ownership rethought [7] we have explained that it is not the star soloists, but the team players that matter in order to limit the stress level in the team while still improving productivity and quality.

Conclusion

Developing software is an intellectually challenging process of many brilliant minds. Software companies are therefore “people” companies. The risk of burnout is real and present given the challenges and pressure in software development projects. We strongly recommend identifying burnout indicators early on or even better continuously to minimize the risk of employees dropping out for months due to overwork or dissatisfaction.

Cape of Good Code has developed an analytical, software-based approach to identify indicators that describe the risk of burnout of an individual caused by working circumstances in software engineering. By using DETANGLE® regularly, project leaders can gain insight about the work-induced stress level within their team. Each indicator gives specific hints of where the stress could come from. This allows project managers to reach out to that employee and discuss individual countermeasures. By speaking with the employee one can definitively clarify how stressful he/she perceives the work circumstances and whether he/she can further handle that stress level.

Frequently Asked Questions

Which requirements must be met so that a software can be automatically examined by the Software Analysis Suite?

During the development of the software, a so-called code repository should have been used, in which individual steps in the development of the source code are stored by the development team. Git as a code repository is used meanwhile to a large extent for it. In addition, information from the bug/issue tracker and its connections to the code repository is used and evaluated. If state of the art development procedures are followed in the use of these tools, immediate configuration and execution of the analysis is possible.  

In other cases, a “pre-project” is required to analyze the inconsistent, non-standard development approach and to clean up the data in order to subsequently perform the software analyses. The results of such a pre-project are technical process improvement proposals for the efficient use of these tools in terms of a standardized development process. It also serves to build up a project memory for the benefit of all stakeholders such as project managers/leaders, product owners and developers and supports software engineering in future projects.

Can the software analyses be performed fully remote?

This is possible and has become the standard in times of travel restrictions. The IT of the company owning/running the software should provide a VPN connection that allows Cape of Good Code to install its DETANGLE® analysis software on a relevant computer (or virtual machine) of the company. The code to be analyzed remains exclusively within the company’s infrastructure at all times. Required personal interviews can also be conducted via online meetings.

Can a software code be too large for an automated analysis with DETANGLE?

A few million lines of code are not a problem to examine in one pass. For >10 million lines of code, it would have to be checked whether the code can be divided into meaningful examination clusters. This is especially beneficial for the accurate interpretation of the analysis results.

Links

[0] Photo by Nataliya Vaitkevich from Pexels

[1] Burnout Prevention for Software Developers

[2] How Not to Burnout: Guide for Software Developers

[3] Beware Burnout

[4] 7 Reasons why programmers burn out

[5] Only You Can Prevent Tech Burnout

[6] Software Due Diligence – Developers and their Cooperation in Focus 

[7] (Collective) Code Ownership rethought