If you can save 5 minutes per day for 500 developers, you save enough money to pay for a whole team?
According to a McKinsey study on Developer Experience, this is the case.
What is Developer Experience?
Developer experience (DevEx, or DX) is similar to CX (customer experience) and UX (user experience) as it looks at the developer experience in using the tools and platforms that they use.
We can look at Developer Experience from two perspectives; one it is the experience of developers outside a company in using their products and APIs (there is even a team in TechLab Products for this – Team Sage), and two the perception and experience of developers inside the company in developing, delivering and supporting our solutions for our customers.
In other words, internal Developer Experience focuses on developer productivity, and external Developer Experience focuses on usability.
In this article, we consider the experience of internal developers only.
Developer experience covers a few different dimensions:
- Perception of their experience of the team, program, and work environment in general.
- Their experience in following processes
- Their experience in using the tools or platforms
The DX.com Approach
One proposed approach for assessing developer experience is to consider three dimensions – Flow State, Feedback Loops and Cognitive Load.
The three core dimensions of developer experience:
Flow State
To be truly productive in a job, being in a flow state – a mental state where when you are performing an activity you can be fully immersed in a feeling of energised focus, full involvement and enjoyment. Studies have shown that for developers this leads to their ability to not only enjoy the work, but perform better and produce better quality products.
Feedback Loops
The goal here is to shorten feedback loops for developers. If you think about it, a typical day consists of many tasks that rely on feedback from people and from tools. For example, waiting for a compiler to finish, waiting for tests (manual or automated) to run, or a code review.
Slow feedback loops interrupt the development process, leading to frustration and delays – meaning that the developer either chooses to wait until the process completes and they get the feedback they are waiting on, or they switch to another task. This causes additional interruption when slow feedback requires immediate attention.
To improve DevEx, we should focus on shortening the feedbacks loops we have by identifying areas where the tools and processes can be accelerated, such as build and test processes and human hand-off processes. If there is an organisational structure that slows us down, such as reviews by someone outside the team, then this needs to streamlined as much as possible as well.
Cognitive Load
As we all know, software development is inherently complex, and we have an ever-growing number of tools and technologies, as well as a host of other tools and processes that add to the cognitive load faced by developers. Congitive load, or the mental processing required for someone to complete a task, as well as all the other things one much keep track of, has a big impact on our ability to not only do our jobs, but also to switch off outside of our work.
Cognitive load for developers can be reduced by finding ways to eliminate unnecessary hurdles in the development process. One aspect is code quality, another is up-to-date and accurate documentation, and another aspect is the ease of use of the tools – ideally tools should be easy to use, and be self-service, that should help developers streamline their tasks for development testing and release. This is where the concept of platform engineering comes in as well – which is a topic in its own right.
Measuring Developer Experience
There are a few approaches for measuring Developer Experience.
One that has been proposed by the people behind a company called DX, and by Nicole Forsgren who was lead researcher and co-author of Accelerate assesses these three dimensions (feedback loops, cognitive load and flow state) against the dimensions of Perceptions and Workflows.
The KPIS are overall perceived ease of delivering software, productivity, and engagement or satisfaction.
GitHub’s Take on Developer Experience
GitHub’s Developer Experience formula takes into account:
- How simple and fast it is for a developer to implement a change on a codebase—or be productive.
- How frictionless it is to move from idea through production to impact.
- How positively or negatively the work environment, workflows, and tools affect developer satisfaction.
One finding from their Developer Experience survey was that collaboration was an important factor in their experience, and wanted collaboration to be a metric in their performance reviews.
The GitHub formula for Developer Experience is:
Why Should We Focus on Developer Experience?
There are a number of benefits that come from focusing on Developer Experience, especially for a software company.
First and foremost, it provides a working environment that helps make work more enjoyable for our developers, making it easier to focus on doing what they love.
For an organisation, it comes with these benefits:
- Talent attraction and retention: We want to attract and hire the best developers and technical staff, and we of course want them to enjoy working here so much that they don’t think about leaving. Studies show developer experience as the number one reason for developers voluntarily leaving their jobs, ranking above salary and benefits.
- Productivity and cost savings: If our developers spend less time on manual, repetitive tasks, on reinventing the wheel, in struggling with red-tape and non-value add activities, it saves time and money. One study noted that if you can save 5 minutes per day for 500 developers, you can pay for another team. According to the 2019 State of DevOps report, developers typically only spend 30-40% of their time developing, and a significant amount of their time going to administrative tasks and delays. A saving of two hours per week for 200 developers results in savings of $2.8 million (assuming 48 weeks of work at $ 150 per hour).
- Consistency and quality: Productising the tools stack and focussing on a great product for developers to use produces great results, far better than struggling with different tools of varying levels of quality.
- Security and compliance: If security and compliance are baked into the tools and make it easier for our developers to meet our security and compliance requirements, it makes their job much easier, and is less time-consuming than trying to do it after the development is completed.
- Speed: Building tools that support the stages of value through the value stream (e.g. from requirements, development, testing and release, and support) helps us to deliver at speed and provide great support.
Examples of DX at Other Companies
eBay
Improving feedback loops and cognitive load are focus areas for eBay, and its internal platform and DevEx organisation is responsible for gathering insights into problem areas to inform decisions around improvement areas.
They measure developer experience through quarterly surveys that capture KPIs such as developer satisfaction and ease of development. The surveys also capture developer perceptions and workflows in different areas of their daily work. This data is augmented by insights from their engineering systems and focus group discussions. Some examples of improvements that came out of the survey data are toiling improvements and addressing documentation gaps, removing manual steps, improving development and release processes, and streamlining cross-team interactions.
Pfizer
Focuses on feedback loops and flow state. Quarterly surveys capture KPIs such as overall satisfaction and engagement, as well as more specific factors such as codebase quality and team autonomy. Teams at Pfizer are empowered to make their own local improvements and are given dedicated time and resources to do so.
LinkedIn focuses on Developer Experience through their Developer Productivity and Happiness organisation, which focuses on three channels to get insights into the experience of their developers. The first is a quarterly developer productivity survey, which asks questions on overall satisfaction, plus satisfaction on the tools and processes the developers use. The second channel gets real-time feedback from developers when they complete a workflow – for example, when pushing a change to GitHub they are asked to rate their experience and provide comments. Finally, they capture metrics from the systems the developers use, such as how long things take to complete (e.g. compile time).
Etsy
At Etsy, they identified four areas or pillars to focus their efforts on for developers and devoted 20% of their development capacity towards improving their processes and technology for their developers.
Each of the four pillars had a designated VP, each of which was required to report to the VP on progress. The four pillars are:
- Help me craft products: focuses on making it easier to deliver features to both sellers and buyers on Etsy. This in practice meant focussing on code improvements such as modernizing their front-end so developers could deliver more easily. It also focusses on libraries and scaffolding for engineers to deliver features.
- Help me develop, test and deploy: focuses on developer tools, test patterns and test execution tools, and deployment tools.
- Help me build with data: enables product managers and engineers to leverage data to experiment quickly and guide the next iterations.
- Help me reduce toil: focuses on reducing tedious or repetitive tasks, including updating documentation and ‘runbooks’ for on-call engineers
DevEx at Booking.com
https://videos.itrevolution.com/watch/827650093/
Developer experience provides a fast, safe, and easy-to-use path from code to production. Remove friction from development workflow.
Pillars of Developer Experience
- Customer focus – the developers are the customers.
- Treat developer experience as a product, with feedback loops, a roadmap, etc. It needs to be somebody’s job. Booking.com has a product leader and a team.
- Shared developer workflow: framework of processes, best practices tools, covers full SDLC. Quality strategy – practices that you should or need to follow.
- Unified Set of Tools
- Freedom with Guardrails – a good way is to templatize things, e.g. golden paths
- Metrics: DORA, adoption metrics, quality, speed
- Embedded security and compliance
- Roof: Leadership culture: a culture that supports a great developer experience
Resources
Articles and Papers:
https://medium.com/swlh/what-is-dx-developer-experience
