The advent of DevOps, cloud-native computing, API use and now AI have made creating software way more complex for developers. These factors have also impacted the developers’ experience and productivity – and how productivity is measured.
No longer do software engineers simply write code and run some tests. Now, they have to manage API integration for required services, security through the use of software bills of materials, the maintenance of these complex applications, and now learn to use AI and understand the risks associated with all of the above.
According to a study released Monday by Atlassian, of the 2,100 practitioners surveyed, the top five areas of developer role complexity are:
- Understaffing – this forces developers to take on responsibilities of other roles (48% of respondents)
- Expansion of the developer role – bringing in testing, security, operations and maintenance (47%)
- New technology – developers need training on such things as AI and other new tech (47%)
- Switching context between many tools – tool sprawl is a big issue for organizations (43%)
- Collaboration with other teams – this can be avoided through more effective use of tools (43%)
Development team leaders say they understand the importance of the developer experience (DevEx). In the study, 86% of leaders believe that attracting and retaining the best talent is nearly impossible without a great developer experience.
Unfortunately, less than half of the developers surveyed believe their organizations prioritize developer experience.
Most organizations today realize that developer experience and productivity are closely related. Andrew Boyagi, head of DevOps evangelism at Atlassian, believes there are three key factors to creating a positive experience: being able to maintain a flow state, reduced cognitive load, and a constant feedback loop. “When developers have access to the information they need in a centralized format and can review progress in regular data-informed retrospectives, they are able to get more work done and have a more enjoyable experience doing it,” Boyagi said.
Among the tactics he said Atlassian has seen success with to achieve that ‘developer hat trick’ are providing powerful DevOps tools, empowering teams to take more control over their roadmaps, and creating an engineering culture “that encourages experimentation and knowledge sharing. But the first and most important step is to speak with your developers. You can’t begin to improve friction points if you don’t fully understand where those friction points are,” he explained.
One technique organizations are using to reduce friction points is through internal developer portals (IDP) and platform engineering. The goal of platform engineering is to standardize tooling, but it comes with both benefits and pitfalls. The obvious benefits, according to Boyagi, are reduced software tool costs and reduced developer complexity created by tool sprawl. Among the downsides are sacrificing best-of-breed tooling that developers have come to rely on, or removing functionality that’s required by specific teams within an organization.
“Creating a positive DevEx is a balancing act,” Boyagi said. “In large organizations, a good approach is to standardize on certain areas of tooling, and allow flexibility in others. For example, it’s logical to standardize on a source code repository, so all code is in one place. You may, however, allow teams to choose from a variety of testing tools. Regardless of strategy, for a positive DevEx it’s important that tools are integrated in a way that minimizes context switching, developers outside the platform team have a voice in the selection of tools, and there is a feedback mechanism for the ongoing performance of tooling.”
Developers as generalists
Ethan Sumner, founder and CEO at research and analysis startup DevEx Connect, said the adoption of DevOps practices has turned software developers into generalists, doing a little bit of a lot of different roles.
“Very early on in my career, I worked for an extremely small company, there were four of us,” he said. “We were all developers, there was no operations. It was just developers, and the operations side was absolutely atrocious. When we did a deployment, it took two days for us to do it, not two minutes, like all these large enterprises have got operations down to a tee.
“And all of our developer environments were built using Oracle VirtualBox, which took three hours to spin up,” Sumner continued. “And it was a productivity nightmare. But afterwards, I went down to MasterCard, where we did operationally things extremely well. Having these kinds of build environments, development environments, a lot of developers just want to develop and code all day; they don’t want to worry about which kind of staging environment, how does it look going into production, a lot of them don’t want to be on call. I think a lot of organizations are trying to put code developers as true generalists, when really, there should still be a bit of segregation between these kinds of roles. You know, people develop, people operate.”
Measuring productivity
Before software became so complex, developer productivity was basically measured in the number of lines of code written per day, or hours working. Today, that fails to take into account the wait times associated with the silos organizations have created to separate out work, as well as other inefficiencies, such as waiting on pull requests or even using time to learn more about testing and security.
According to the survey, 41% of organizations use tools that measure developer productivity to assess development team satisfaction. This, the survey said, raises a red flag about whether or not an organization is tracking the proper metrics with the correct tools.
“Our survey found that more than half of the engineering leaders using [these kinds of] metrics … find them ineffective as a measure of developer productivity,” Boyagi said. “While you can measure productivity, there is no one metric, or set of metrics that rules them all. This is because developer experience and productivity are highly contextual between teams and organizations. Organizations need to look at things from a 360-degree view and focus on three things: developer sentiment (how they feel about their work and environment), workflows (how efficient and reliable systems and processes are), and KPIs (the measures your team obsesses over, based on your specific situation).”
Will AI be a game-changer?
A study by IDC predicts that $40 billion will be spent on AI tools this year. And Atlassian’s study found that development leaders believe that using AI is the most effective way of improving both productivity and satisfaction.
Yet only 30% of responding developers said AI-based development tools will improve personal productivity, and 32% responded “only slightly.” This continues to show the disconnect between how leaders view productivity and satisfaction, and how developers see it.
“AI can help improve developer experience, but it can’t solve all the pain points of development teams to improve productivity and satisfaction,” Boyagi noted. “There is the potential for significant gains in things like incident response, info searching, and documentation but only if applied as a solution to an actual issue developers in an organization are facing. It’s critical for leaders to ask developers about their friction points and then focus on implementing the right solutions and cultural changes to make a difference.”
You may also like…
IDPs may be how we solve the development complexity problem
Q&A: Why over half of developers are experiencing burnout