There is no lack of high-stress industries and occupations that have to battle against burnout and employee fatigue. They’re problems that face a number of jobs – from hospital staff to airline pilots. But, when you think about occupations that deal with fatigue and burnout, application developers may not be top of mind.
However, as the application development process has accelerated, and as dev teams have begun deploying new capabilities, patches, and updates with increased frequency, burnout has become a real problem.
In a recent article in The New Stack, James Brotsos – a Senior Solutions Engineer at Checkmarx with 15 years of network protocol and kernel development experience – discussed the employee fatigue problem facing development teams.
“This increased pace and immense pressure surrounding software development have made burnout an even bigger reality than before, at a time when developers couldn’t be more essential to maintaining business continuity,” Brotsos explained. “The negative consequences of this trend have mental and physical health implications for developers who are finding themselves in a constant cycle of aggressive productivity.”
To help battle the burnout resulting from this cycle, James provided four steps that organizations can take to ensure that developers are faced with less pressure and – subsequently – less burnout. they include:
Increase Training, but Make It Enjoyable
One of the most effective tactics in preventing burnout is to ramp up secure coding education and training. While this might feel counterintuitive as if it’s adding yet another task to developers’ plates, when done right, these initiatives can have lasting effects that help them become more aware of common security issues and capable of remediating them in a timely manner.
Where many training programs often fall flat is that they’re boring, forced, and take developers out of their usual routines and workflows, all big reasons why they often get a bad rap. In order to really break through to developers and make a real impression — and in turn, drive real change with how security is implemented into software development — training initiatives should take a more gamified approach to keep developers engaged and entertained.
For instance, these training modules can be turned into tournaments, which promotes friendly competition. You can add fun prizes or (virtual) events for folks to come together and learn while having a little fun. I also recommend delivering lessons in short, frequent bursts to keep security top-of-mind in their daily operations without the draining stigma associated with half or full-day training sessions. These integrated bite-size, relevant training modules can be inserted directly into a developer’s daily routine so that developers do not have to endure hours of out-of-context training sessions.
If you provide your developers with the proper training to think about security from the beginning stages, you have the ability to curb stress later on by minimizing the chance of major vulnerabilities.
Share Security Responsibility and Ownership
There’s a common misconception that security is the responsibility of developers and developers alone. Not only is it untrue, but it’s also an inadequate mindset given today’s evolving threat landscape. It takes a village when it comes to security and there needs to be concrete alignment between DevOps and AppSec teams and employees in other departments to create a comprehensive security program.
I recommend having the AppSec team lead the strategy around security procedures, with input from the developers who are on the frontlines executing it in the wild. If there are apparent gaps in security protocols, developers should advocate for the tools and resources they need to achieve a strong security posture. The application security testing (AST) space is made up of many different solutions, with one goal in common — to secure software. Generally, static application security testing (SAST) and software composition analysis (SCA) are two of the better known and used solutions. Though, in the last few years, we’ve seen more attention on Interactive Application Security Testing (IAST) as well.
Regardless of the AST tool your organization invests in, ensure it aligns with your overall AppSec strategy and fits seamlessly into your existing workflows and CI/CD pipelines. Nothing will make developers resent the idea of security more than trying to fit a square peg in a round hole when it comes to testing solutions. Remember that the end goal is to alleviate their workload and optimize their coding processes in a secure manner.
Automate, Automate, Automate
Many functions in the world have become automated to make our lives and jobs easier. Just as self-driving cars are no longer an abstract thought of the future, key functions within the developer role and the AST tools they use are now being automated to make security simpler. In fact, 30% of DevOps leaders are prioritizing “software development life cycle” (SDLC) automation in 2021, according to an analyst study.
It’s no hidden secret that developers often view security as a burden as part of their day-to-day coding processes. However, more often than not, this scenario plays out because they don’t have access to tools that make embedding security into their CI/CD pipelines seamless and easy.
By implementing automated security testing tools — especially those that cover proprietary and open source code — scans can be automatically triggered, with results prioritized based on severity. With this ability, developer workflows are streamlined and they’re able to find and fix flaws more confidently without compromising speed and security, ultimately allowing them to do what they do best and love most — coding.
Modern automation tools create a seamless way for developers to catch and fix vulnerabilities during the earliest coding phase. In turn, developers can easily address and remediate security bugs and functional flaws while reducing the overhead of manually opening, validating, and closing security tickets. This alone saves countless hours for developers.
Have the Tough Conversations
Providing the right training and automation tools is just the tip of the iceberg. Alleviating some of the aforementioned burdens on developers doesn’t automatically mean they are less stressed. If you’re in a leadership role or are tasked with managing a development team, check-in with them frequently. Having a constant pulse on the morale of your employees and their stress levels will empower you to make the necessary changes before it reaches a point of burnout.
Yes, software needs to be built and delivered faster, but this shouldn’t come at the expense of developers’ mental and physical health. Collaborate with leadership and encourage an open-door policy so that developers can come to you to talk about issues they are facing in their day-to-day work environment. This will ensure less burnout and turnover, while also boosting morale and leading to greater software integrity, quality, and security.
Read the original article on GovDevSecOpsHub here.
Related Blog Posts
