adam121 - Fotolia
Ending the cycle of rush and burnout in software development
Instead of focusing on speed in software delivery, addressing risks affecting on-time delivery is the secret to preventing burnout
Around two years ago, with the help of the polling firm Survation, I studied developer burnout and found that 83% of developers reported suffering from burnout.
Over the past few months, I’ve studied the state of software engineering in detail - from what matters to the public in software systems to software engineering facing retaliation for speaking out. Asking software engineers again if they suffered from burnout on the 25th of October 2023, the burnout rate is 79% - meaning that despite the end of the pandemic and new approaches being taken to address these challenges, we’ve failed to see a statistically significant decrease in burnout.
New research has finally shed light on how the cycle of rush and burnout amongst software engineers can be addressed for good.
When software engineers were asked by Survation about what is most important to them when doing their jobs, “delivering work quickly” came bottom - with factors like reliability and security coming top. The general public agrees with this, with “getting the latest features as quickly as possible” least important to them (also when asked by Survation, from 29th September to 8th October 2023).
However; a review of scientific material found that approximately 70% of software projects fail to be delivered on time, despite 83% of software engineers rating the importance of on-time delivery performance as high or very high. This differentiation between on-time delivery versus fast delivery is the first crucial insight addressing this challenge.
My research with Survation also found that when software engineers were asked to select the single most important measure of quality for their current project at work, of 13 different dimensions, “delivering work quickly” was the second least important factor. However, “delivering work on-time” was the most important factor selected.
Having studied attitudes among the general public and software engineers, I recently worked with research agency J L Partners, to study attitudes amongst business decision-makers (research conducted from the 28th to the 29th of November with 500 UK and US business decision-makers). The poll found that 93% of business decision-makers in the UK and 95% in the USA consider on-time delivery as important when evaluating the performance of software engineering teams (63% saying “very important” in the UK and 66% in the USA). Despite the high importance placed upon on-time delivery, 81% of business decision-makers in the UK and 89% in the USA are concerned about about on-time delivery of software projects in their organisation (44% of respondents in the UK and 57% in the USA said they were “very concerned”).
Even though predictability (ie on-time delivery) is such a paramount concern, metrics frameworks like Google’s Dora (DevOps Research and Assessment) Metrics, alongside the successor frameworks of SPACE (which captuires the human and social factors that inflence productivity) and DevEx (developer experience), have focussed on measuring “productivity” by essentially measuring the speed of delivering work (or the speed to respond to problems).
Exploring this further with Haystack (which runs a software delivery ops platform), what we now see is that unmitigated risks of project delays. Developer productivity solutions have sought to address this by getting developers to ship ever-faster when they encounter unmitigated risk, which will inevitably lead to greater burnout amongst software engineers.
This causes an endless cycle of failure to deliver on-time, leading to tougher expectations (now often enforced by productivity metrics), leading to developer burnout. Developer burnout inevitably leads to problems which result in greater failure to deliver on-time.
The solution however is to address the desire of businesses to be able to commit to work based on informed delivery timescales, without unmitigated risks appearing which affect on-time delivery of software. From requirements being unclear and deadlines not being agreed (or even communicated) with developers, to issues in the software development process itself, mitigating these risks offers the solution to developer burnout.
Dr Junade Ali CEng FIET is an experienced technologist with an interest in software engineering management, computer security research and distributed systems.
Read more about developer burnout
- Ceridian has developed a 'burnout dashboard' to identify employees experiencing work fatigue
- DevOps burnout is more common than you think. Pay attention to the details in your Java shift left to make sure your dev and management teams are working toward the same goals