Developer burnout is more widespread than you might think. With DETANGLE® you can automatically detect early indicators of burnout from the work on code.
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]:
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:
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:
| Category | Example |
| Lack of focus (A) | Too many varying tasks. The developer e.g. works on the development of many new features but just a few will be completed.
Or the developer constantly switches between maintenance/bug fixing and feature development often without finishing previous tasks. |
| High workload and/or unbalanced distribution of tasks (B) | High workload for some top developers, as only they have the skill to handle complex parts of the software.
A single developer has to coordinate the work of many (new) developers. Unrealistic deadlines coupled with notorious understaffing. |
| Significant share of “non-value” work (C) | A high share of maintenance work and a low share of the development of new features/innovations becomes frustrating in the long run. |
| Bad collaboration within and between development teams (D) | Lack of onboarding/training of new colleagues.
Experienced developers who do not delegate or share their knowledge. Lack of communication about work progress and best practices within the team or between teams. |
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.
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®:
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.
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.
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.
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.
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.
[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
Cape of Good Code can determine an unhealthy level of stress in software projects and which developers might be most affected.
Cape of Good Code's software analyses provide data-based help in allocating the ever-scarce development resources in software engineering
In order to conclude better contracts for better software when purchasing customised software, a rethink and new tools are needed in purchasing.