Arrow icon

State of the Developer
Experience 2024

Download PDF Version

We surveyed 500 engineering leaders and practitioners

In partnership with Wakefield Research.

The overarching goal of DevOps is to foster collaboration, automation, and a continuous delivery pipeline that enables organizations to rapidly and reliably release high-quality software products and services. However, achieving this goal is often hindered by various challenges, particularly related to the competing priorities and tool silos.

This disconnect has led to a situation where the vast majority of developers, estimated at around 30 million globally, are left to build their own internal tooling and processes for development, testing, and deployment. These ad-hoc solutions often lack the robustness, scalability, and standardization required for enterprise-level software delivery.

Consequently, organizations struggle to achieve the desired level of automation, visibility, and collaboration across the entire software delivery lifecycle. Siloed tools, processes, and mindsets hamper the ability to establish a seamless, end-to-end pipeline that enables rapid iteration, continuous integration, and automated deployment to production environments.

As illustrated by our research, to overcome these challenges and truly realize the goal of DevOps, organizations must foster a cultural shift that emphasizes collaboration, shared responsibilities, and a common set of goals between development and operations teams. This requires breaking down silos, implementing standardized tooling and processes, and promoting open communication and knowledge sharing across the entire software delivery lifecycle.

How many tools

Developers manage 14 different tools on average

Managing too many vendor tools can be a daunting task for developers, often leading to inefficiencies and complexities in their workflow. The proliferation of multiple tools from different vendors can create a fragmented ecosystem that hampers productivity and collaboration within development teams.

54
%

of developers say it takes longer than a week to learn new DevOps tools

It would take a new developer 100 days to onboard, considering the multitude of tools involved.

One of the major challenges of using multiple vendor tools is the need for plugins and patches to ensure integrations will work. Developers often find themselves spending valuable time troubleshooting compatibility issues, updating plugins, and applying patches to make the tools work harmoniously.

59% of developers say it takes a week or longer to build internal tooling.

This not only adds to the workload but also introduces potential points of failure in the development process.

97
%

of developers say

they context switch because their tools are from multiple vendors.

Having to juggle multiple tools also means that developers need to switch between different interfaces, learn varying workflows, and manage separate accounts and licenses.

This can lead to confusion, cognitive overload, and a lack of consistency in the development environment.

In contrast, having a unified platform that provides a centralized hub where developers can access all the tools they need can streamline the development process and enhance efficiency.

A single platform provides a centralized hub where developers can access all the tools they need without the hassle of managing multiple vendor relationships and dependencies.

That may explain why 62% of executive buyers would prefer a platform versus siloed tools.

By executing next-generation software delivery platform initiatives (e.g. improved performance, increased consistency, and reduced maintenance) via tools consolidation across the enterprise, organizations have an opportunity to realize the following benefits for every 1000 devs:

Formula:

Formula showing developer productivity: 1k developers x $100k annual salary equals $100M; 1k developers x 2000 annual work hours equals 2M hours; tools consolidation resulted in 52% productivity improvement equaling 1.06M hours; 15% of productivity improvement time spent on deployments equals 159K hours; 159K hours x $50 per hour equals $7.9M.

How slow the processes are

60% of organizations are still releasing code on a monthly or quarterly basis

In today’s fast-paced business environment, organizations that adhere to monthly or quarterly release cycles for code deployment may find themselves falling behind the curve. 


The demand for rapid innovation, quick response market changes, and continuous improvement necessitates a more agile approach to software development and deployment.

42
%

of developers think deploying code to production isn’t fast or efficient either

44
%

of developers think testing code end-to-end isn’t fast or efficient

Waiting for extended periods between releases can lead to delays in delivering new features, addressing critical issues and responding to customer feedback promptly. This lag in deployment cycles can hinder your organization’s ability to stay competitive and meet the evolving needs of customers in a timely fashion.

Similarly, fast and efficient code reviews play a crucial role in ensuring the quality and reliability of the codebase. Delayed code reviews due to lengthy release cycles can impede collaboration, feedback exchange, knowledge sharing, but most importantly, they can delay services being provided to your users.

Timely code reviews are essential for identifying and addressing potential issues early in the development process, improving code quality, and accelerating the overall delivery timeline.

of developers have attested to waiting over a week to complete code reviews.

But this lack of urgency is not only having an impact on services, it’s also affecting incident response. Minimizing downtime and swiftly restoring services in the event of disruptions is paramount for organizational resilience and customer satisfaction.

61% of developers cite a week or longer is the average time to restore services in their organization

Rapid deployment practices, coupled with robust monitoring and incident response mechanisms, are essential for maintaining operational continuity and mitigating the impact of downtime on business operations.

By taking on inefficient technology in the workplace initiatives such as increased SDLC speed / agility / TTM, or higher quality deliverables via reduced Change Failure Rates, the potential annual benefits for every 1000 devs are:

Formula:

Green gradient infographic showing productivity and cost calculations involving developers, annual salary, work hours, change failure rate reduction, and productivity improvement.

Developer toil and lack of automation

42% of developers say they can’t release code to production without risking failures

Releasing code to production without failures is paramount for organizations striving for operational excellence, customer satisfaction, and business continuity. Despite this fact, our survey reveals organizations are still struggling to deploy code reliably and ensure an uninterrupted user experience.

Another metric to monitor the ability of releasing code confidently is the change failure rate.

A high change failure rate, where a significant portion of code deployments result in issues or disruptions, can have detrimental effects on the organization's reputation, customer trust, and bottom line. Frequent failures not only lead to service interruptions and downtime but also erode confidence in the development process, hinder innovation, and impede progress towards achieving business objectives.

39% of developers experience failures at least half the time

But how does this environment take root? Ultimately, everything just discussed is the summation of activities known as developer toil.

What is Developer Toil?

Developer toil can be characterized by repetitive, manual, and low-value tasks that consume significant time and effort.

When you have a solid developer experience, you can accelerate the development process by streamlining workflows, reducing friction, and enabling developers to focus on solving complex problems rather than dealing with technical hurdles.

Let’s examine building and testing artifacts for example.

The capability to build and test artifacts quickly is crucial for maintaining a rapid and efficient software delivery pipeline. Swift artifact creation and testing processes enable developers to iterate on code changes rapidly, identify issues early in the development cycle, and accelerate the time-to-market for new features and updates.

28% of developers say it takes at least a day or longer to build and test artifacts.

Streamlining build and test workflows enhances productivity, fosters collaboration, and facilitates the timely delivery of high-quality software products.

Now what happens if a release needs to be rolled back? Automated rollbacks are a preferred tactic as manual rollbacks present a set of challenges that can impede the efficiency, reliability, and agility of software deployment processes.

of developers currently execute manual rollbacks

While rollbacks are essential for reverting to a stable state in the event of deployment failures or issues, relying on manual intervention for rollback procedures introduces complexities and risks that can impact the overall effectiveness of the rollback process.

But why were these errors even able to get through to production?

High unit test coverage plays a vital role in ensuring code reliability, functionality, and maintainability. Unit tests validate individual components of the codebase in isolation, helping to detect bugs, regressions, and inconsistencies early in the development process.

32% of developers say there isn’t high unit test coverage.

Comprehensive unit test coverage provides developers with confidence in the stability and correctness of their code, reduces the likelihood of introducing defects during deployment, and promotes code quality and consistency across the project.

And while these technical pain points that developer toil presents are detrimental to your DevOps processes, the ultimate victim are your actual developers. Developer toil can have a profound impact on developers' well-being, productivity, and work-life balance, leading to increased instances of working overtime.

23% of developers are working overtime at least 10 days a month

By taking on inefficient technology in the workplace initiatives such as increased SDLC speed / agility / TTM, or higher quality deliverables via reduced Change Failure Rates, the potential annual benefits for every 1000 devs are:

Formula:

Infographic showing developer cost and productivity calculations: 1k developers times $100k annual salary equals $100M; 1k developers times 2000 hours equals 2M annual work hours; reduced TOIL resulted in 37% productivity improvement equals 740k hours; 15% of productivity improvement time spent on TOIL equals 111k hours; 111k hours times $50 per hour equals $5.5M annual work hours.

Security and governance

59% say that their AppSec requirements limit their ability to release code frequently

And if that’s the case, only one of two things can be sacrificed – either innovation or security. If you’ve been in DevOps for long enough, it won’t surprise you to discover that security is often sacrificed in order to meet the needs of the business.

40% of developers admitted that their organizations don’t enforce good security and governance policies across the lifecycle.

41
%
42
%

of developers don’t have automated security and governance policies

of developers don’t have robust identity and access management policies

The absence of automated security and governance policies means that developers may overlook critical security measures. This can lead to vulnerabilities in the code, making it easier for malicious actors to compromise the software. Speaking of, without proper controls in place to manage user access and permissions, you run an even higher risk of breaches and unauthorized access to sensitive data.

Adopting a Shift-left Security initiative such as DevSecOps to help developers maintain high velocity while also ensuring the application services are highly secure. The potential annual benefits for every 1000 devs (for every 100 security incidents):

Formula:

Formula calculating security incident impact: 95% of security incidents were duplicates equals 95 incidents, 10% of 1k developers respond equals 100 developers, time spent per security incident is 4 hours, total 38k hours, costing $1.9m at $50 per hour.

Impact to developer

52% of developers cited burnout as a reason their developer peers leave their job

Developer burnout can occur when developers are consistently overworked, under constant pressure, and facing an onslaught of tight deadlines. Not only can this lead to a lack of productivity, but burnout can also lead to physical and mental consequences. For these reasons, it’s not unlikely for organizations to experience high turnover from overworked developers.

As evidence, 45% of developers surveyed say they don’t have enough time for learning and development. And executives seem to agree.

71% of executive buyers said that onboarding new developers takes at least 2 months

As reported earlier, it would appear that context switching plays a role in this delayed onboarding experience as 97% of developers admitted that they context switch throughout the day.

It doesn’t help that 62% also experience scope creep with expanding requirements, which means they are taking on more with less confidence to execute.

This has had a profound impact on developer attrition.

Of executive buyers admit that if they reduced the number of errors in the development process they would increase retention

If you still deploy off hours (weekends / evenings / holidays) or experience deployment related downtime/incidents which results in a negative developer experience, then the potential annual impact of 1000 devs adopting strategic DevX initiatives such as Agile, DevSecOps, and Platform Engineering methodologies is:

Formula:

Formulas showing developer work cost and time: 1k devs x $100k salary = $100M; 1k devs x 2000 hours = 2M annual work hours; 20 devs per incident x 1.44k hours = 28.8k hours spent on code-related incidents; 240 code-related downtimes x 6 hr MTTR = 1.44K hours; 28.8k hours x $50/hr = $1.4M.

Conclusion

In the ever-evolving landscape of software development, developers face a multitude of challenges in orchestrating the complex processes involved in building, testing, and deploying applications.

Traditionally, many development teams have relied on a patchwork of disparate DevOps tools, each addressing specific aspects of the software delivery lifecycle. However, this approach often leads to fragmentation, inefficiencies, and a lack of cohesion, hindering the very goals that DevOps aims to achieve.

To overcome these limitations and unlock the true potential of DevOps, developers must adopt a platform-centric approach. By consolidating tools onto one platform, developers can benefit from a cohesive user experience, seamless integrations, and consistent updates across all functionalities. This not only simplifies their workflow but also fosters better collaboration, communication, and knowledge sharing among team members.

It’s also worth noting that a platform-centric approach offers seamless integrations and simplifies the process of keeping all tools up-to-date and aligned. Instead of managing updates and compatibility across multiple vendors, developers can rely on a single platform provider to deliver consistent updates and enhancements across all functionalities. This not only ensures that the development team is leveraging the latest features and improvements but also mitigates the risk of compatibility issues or technical debt associated with outdated tools.