Developer Experience (DX) has emerged as a crucial factor in the success of any software development project. At its core, DX represents the overall happiness, productivity, and ease with which developers can create high-quality work. But how can you truly measure the DX of your project?
Fortunately, there are specific metrics that can tell you whether your project delivers good DX. In this article, we’ll share what these metrics are, drawing on our experience with past clients.
Developer Experience, or DX for short, is an area of expertise focused on the environment in which developers work. It optimizes their interaction with tools, technologies, teams, and processes.
For example, Developer Experience could minimize code editor crashes, ensure the development environment is stable, and verify if the documentation is helpful.
Taking care of your team's developer experience leads to improved productivity.
Your developers have better focus on coding and solving actual problems once you free up the time they normally spend optimizing their setup or waiting for their tools to load. In other words, having fewer obstacles means they will reach their goals faster.
Good DX also boosts team morale, which helps you retain your best talent. With their work environment being efficient and free of roadblocks, developers are less likely to look for another job as they are satisfied with their current one.
A definition of a good Developer Experience will be slightly different for each project. However, in our experience with businesses of all sizes, a good DX will have these 8 key elements:
When working with our clients, we discovered how each of these elements contributes to improving the Developer Experience.
| The key element | Its importance |
| Code-test/run loop under a minute | It enhances productivity, boosts motivation, and enables agile development practices while also being cost-effective. Given that developers can now write entire features within seconds using LLM-based agents, it would be counterproductive for them to wait minutes for the build and testing process to complete. |
| A coherent development environment, composed of tooling that is reliable, fast, and trustworthy. | A development environment needs to be stable and provide all required tools, configurations, and best practices. It should also feature automatic or semi-automatic configurations, including IDE, VCS, build tools, deployment tools, package managers, and any custom tools or scripts. The development environment should also facilitate quick onboarding for new team members. |
| Proper flow for automated tasks and checks | Proper flow for code generation, linting, formatting, and other automated checks enhances DX by saving time, reducing errors, and streamlining code reviews. Often, those tools get in the way rather than helping, but automation should be the name of the game for software development. |
| Streamlined code review | Code reviews should be done on time, be of high quality, and use the aid of guidelines and checklists. Also, developers shouldn’t have to repeatedly request code reviews from their seniors. |
| Stable and useful CI | CI should be stable, trustworthy, quickly provide meaningful test results, and run only the necessary tests. CI should also scale and be cost-effective without compromises on trustworthiness or correctness. |
| CI, test and production environments, and access rights that are easy to acquire and manage. | New joiners should receive all necessary access rights immediately, with a swift request and approval process. It should be well documented which access rights are required for what. |
| Clear ownership structure with suitable support available | The code, the processes, releases, etc. should have clear ownership. This means that there should a clear escalation and support paths for developers to get help with fixing problems within any part of the system and project environment. |
Creating a smooth and efficient environment for developers to work with is a goal that spawned different ideas and approaches.
For instance, building and maintaining a stable and functioning working environment is the main goal of DevOps engineers. Then there is Developer Productivity, an important metric for project managers and product owners. In both cases, there is a clear connection to Developer Experience.
While referred to by different names, Developer Experience (DX) has existed since the early days of software development. Back then, dedicated teams were already focused on improving it. Later, DevOps emerged as a solution to some of the problems these teams were solving.
The connection between the two is that poorly designed DevOps can weaken the Developer Experience.
At VirtusLab, we provide developers with a stable and productive environment, accessible with just a few clicks. The above definitions serve as the guidelines that we follow to deliver such environments to our clients and their teams.
Other factors contribute to improving the Developer Experience as well. While still important, they can be added at later stages once the previously mentioned key elements have been taken care of. Some of these additional factors to consider for improvement are:
Typically, Developer Productivity is a term that describes how effectively your team produces high-quality code. One of the factors that can increase Developer Productivity, is having a good Developer Experience.
Developer Productivity metrics will differ for each project. In our experience, it's best to track aspects that we are optimizing for the client:
One set of metrics used to measure Developer Productivity is the DORA metrics.
DORA metrics are an officially established method for measuring developer experience. Created by Google, DORA stands for DevOps Research and Assessment. A team at Google identified 5 (initially 4) key metrics of the software development team’s performance.
In our experience, there are multiple ways to measure Developer Experience.
A Developer Experience team consists of an individual or group dedicated to addressing specific types of problems. This might be a software engineer managing the Integrated Development Environment (IDE), or a team responsible for every aspect of DX for a given project. Instead of delivering new features and writing code, the primary focus of DX teams is to ensure that other teams can work smoothly. We noticed that a small team of about 5 to 10 people can make a noticeable difference for a group of 1000 developers.
At VirtusLab, we have centralized our Developer Experience teams within a dedicated department to bring the most value to our clients. It specializes in improving development processes through a variety of IDEs and other tools and develops various dedicated developer tooling, such as custom IDE integrations.
Over the years, we have noticed that our clients come to us with similar problems.
From a technical point of view, these problems can have different sources. This is why we tailor our services to each project. For example, to avoid disrupting day-to-day activities for one of our clients, we released improvements to the code review process in small iterations.
It's this focus on tooling, combined with a tailor-made approach, that has allowed us to successfully improve DX for our clients.
