olly - Fotolia
Can a left shift in Java cause DevOps developer burnout?
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.
As the DevOps movement blossoms, many organizations have adopted the shift-left mantra as a way to improve software quality. While this works great for some organizations, it can also lead to DevOps developer burnout if management implements shift left in Java dev environments without the right tools or the proper foresight.
A shift left in Java can also slow development when DevOps developers spend more time troubleshooting problems, rather than using the move-fast-and-break-things method espoused by Facebook founder Mark Zuckerberg.
"The more a company pushes left in the software development cycle, the longer the cycle time is -- that's the tradeoff," said Anders Wallgren, CTO at Electric Cloud, a continuous delivery platform based in San Jose, Calif. "You've shifted too much work to the left when it inhibits the flow of fast feedback to DevOps developers about the code changes they are making."
A good approach to avoid DevOps burnout is to look at what's appropriate to shift left. Certain things should happen as early as possible, while other things are either too expensive in terms of system time, human capital or other resources.
Automate first, shift left later
A good place to start is to figure out how to automate testing. An organization needs to understand that its development teams should write tests that are appropriate for the functionality it creates, the bugs it fixes or the performance it tries to improve, Wallgren said. It's the organization's job -- and specifically the developers themselves or the QA team -- to find the right place to insert any particular kind of test in the software delivery and continuous integration pipeline.
However, you need to make sure these tests are properly orchestrated and don't create redundant testing. For example, development teams don't want to have unit tests that masquerade as integration tests, because problems will arise if the tests take too long. The value of a unit test is highly proportional to how long it takes for the testing tools to run it.
"If the only value derived from an integration test is that it's really a unit test, that's a really expensive way to run a unit test and is disproportionate to the opportunistic value of testing in the first place," Wallgren said.
If a developer has to fix a failing test or a bug that triggers a test to fail, it can quickly become an expensive and frustrating process. It can also take time away from other activities, like writing code, which typically provides way more value in the long run. A better practice is to constantly evaluate the software delivery pipeline to determine which tests go where -- and why -- and build as much automation around that process as possible.
Automation is a key factor on how to reduce a developer's workload and provide them with more time to concentrate on what is important.
"There are only so many hours in a day, so any increase in developer responsibility needs to be matched with increased efficiency. Otherwise, their productivity will suffer," said Al Sargent, vice president of product marketing at Applitools, a visual UI testing and monitoring service based in San Mateo, Calif.
Measure DevOps burnout
Good metrics can help identify when developers are overburdened and DevOps burnout is imminent. Wallgren noticed that when large engineering organizations have too much work, they tend to write fewer unit tests. The lack of unit testing in code check-ins should be a warning sign of developer burnout.
Another sign of a lack of staff skills or training is when engineers write complicated system or integration tests instead of unit tests.
"If you're reviewing unit tests and you have test methods that are like two or three pages worth of code, that's a telltale sign that somebody isn't doing the right thing," Wallgren said.
A good DevOps strategy is to make sure developers can do the following:
- get up to speed quickly;
- deploy their own code into production, but also ensure their deployments work without simply waiting for the app to break; and
- have a rollback strategy that works in minutes, rather than hours.
