Tech Insights / Developer experience

Developer experience: Optimizing DevOps UX

The cloud native ecosystem—which has become synonymous with Kubernetes, containers, cloud and DevOps—gives developers access to a vast array of new tools, but that diversity comes with certain challenges. There is a steep learning curve associated with developing applications for Kubernetes, and the landscape of cloud native tools, dominated by CI/CD and DevOps tools, exacerbates these challenges. Combined with public cloud offerings specifically designed to serve app developers, the situation quickly becomes confusing. As organizations adopt cloud native methods, they may face a development experience crisis due to the complexity and newness of the cloud native ecosystem. Cloud native software development must be treated as a core competency in order to fully unlock developer potential and deliver new software and services more quickly.

DevOps is a set of development best practices that integrate software development (Dev) and IT operations (Ops) with automation. DevOps incorporates agile software development methods for fast and frequent iteration to deliver new software features quickly and predictably.

Cloud native applications encapsulate code in containers and use Kubernetes to automate the process of deploying, operating, and scaling those applications. Kubernetes and the associated broad landscape of cloud native tooling and services directly affects the user experience (UX) of developers, increasing the cognitive load and potentially impeding progress. There is a need to optimize the tools and workflows used by software engineers to provide a “developer platform” that offers a better, more consistent development experience and prevents developer burnout.

What is developer experience?

Developer experience (DevX) is a measure of how a developer interacts with the resources necessary to do the job. In other words, how productive and efficient are developers as they use the systems and tools provided (possibly systems and tools they selected themselves or helped to choose). Do they know what tools they need for each process and can they access them easily? Are tools or processes easy to use or confusing? Does everything work as expected? How much manual toil is required to complete critical tasks?

Ensuring a good DevX is important to your organization and has many benefits. You can recognize signs of a positive DevX when developers:

  • Are working to create applications—not toiling with environment configuration, tool chain integration, and infrastructure setup.
  • Deliver robust, scalable applications.
  • Ship software quickly in response to changing market dynamics or customer needs.
  • Deliver business value.
  • Stay on the job. With so many job opportunities, high developer retention is a positive indicator.

If your DevX is poor, you may notice developer burnout, workflow inefficiencies, and difficulty adopting new tools or delivering new software features. Even if your team is extremely experienced, a poor DevX hinders successful development and contributes to attrition.

Benefits of good developer experience

Developers aren’t motivated solely by salary. The 2022 State of Software Engineers report found that the biggest motivator was “new challenges and continuous learning,” followed by “building products/solutions and problem solving.” Delivering on goals like this is part of DevX. A positive DevX benefits the entire organization with development teams that are:

  • Motivated
  • More productive
  • Write better code in less time
  • Stable with low attrition rates

With a good DevX, developers are better able to optimize workflows, decrease redundancy, and take ownership of successes and failures.

A good DevX also provides a friction-free interface between development and operations, enabling a DevOps approach with clear delineation of responsibilities—and creating a collaborative team culture that harmonizes the developer experience and the operator experience. Delivering a good DevX paves the road to productivity and reduces risks such as delays that result from broken builds, quality problems, and security risks such as the introduction of CVEs into new code.

What to consider to improve developer experience

There are a number of metrics that will help you understand where your developers fall on the DevX spectrum from good to bad. Together, these metrics provide a frame of reference to measure developer experience. By measuring developer experience metrics relevant to your business, you can move DevX in a positive direction.

The field of developer productivity engineering (and the title of developer productivity engineer) are emerging in response to the need to deliver development platforms that are able to deliver a better developer experience and improve the speed and quality of software delivery.

Usability: ease of use for developers

Usability is a measure of the experience when interacting with products or systems, software, devices, or applications. Usability relates to effectiveness, efficiency and the ease of use of a developer platform. Usability factors include:

  • Intuitive design. Are interfaces to a tool or system easy to understand and navigate?
  • Ease of learning. How fast can a developer learn what they need to know and accomplish necessary tasks?
  • Efficiency. How fast can an experienced user accomplish necessary tasks?
  • Error frequency and severity. How often are errors made, how serious are they, and how quickly can a user/team recover?
  • Subjective satisfaction. Does the system, tool or device provide a good user experience?

Findability: ease of incorporating desired functionality

Findability is a measure of DevX when users are navigating the complexities of the cloud native ecosystem to incorporate needed functionality into an application. Developers need options, particularly for languages, frameworks, and databases—the foundational technologies used to build applications. On the other hand, offering too many options can often be detrimental.

An effective developer platform should provide:

  • Internal developer portal. An internal portal enables self-service and allows developers to find everything they need in one place. According to Gartner, the benefits of a good portal include reducing friction, enhancing collaboration, accelerating the speed of incident resolution, and fostering innovation.
  • Kubernetes abstraction layer. Don’t make developers wrestle with the complexities of Kubernetes, help them keep writing code. It’s likely that you use multiple flavors of Kubernetes in multiple clouds. The right abstractions can protect developers from environmental differences, making them more productive wherever they are working.
  • Preconfigured templates. Templates help developers bootstrap new applications without reinventing the wheel or requiring a lot of manual toil each time.
  • Consistent user interface. Interfaces should bring services and APIs together in one place, making them easy to discover and integrate with other apps.

Thorough documentation of user resources, including the platform itself, is important. The documentation must be easy to navigate. Bad documentation for any resource can impact the overall DevX.

Credibility: stable and reliable architecture

Credibility boils down to one question, can developers trust their resources? Tools and processes need to be reliable and stable, always available, and do the job they are intended for. A good DevX doesn’t arise from tools, systems or processes that they aren’t aware of (an area where a developer portal helps), that don’t perform as expected or don’t produce the desired result.

Value: Do resources benefit a developer?

Value can mean different things to different people, but developers need tools that are functional and have a good interface for their needs. They must be stable with high performance and reliability, and they must be quickly fixed if problems occur. They should add speed to the development process and be supported with documentation, communities, and use cases.

Tracking DevX improvement

Simple metrics you probably already track for DevOps purposes often correlate with DevX improvement.

  • Deployment frequency. Successful teams deploy several times a day, less successful teams may only deploy once a week, once a month or even less often. More frequent deployments indicate a higher DevX.
  • Lead time for changes. How long does it take to go from committing code to code running successfully in production? High performing teams often take less than a day. Low performing teams could take a month or more.
  • MTTR. Mean time to repair or MTTR is the average time it takes to return non-functioning code to full functionality—including testing time.
  • Change failure rate. A measure of the percentage of deployments that cause a failure in production.

All improvements in these measurements map to improved team performance, an indicator of improving DevX. If these metrics are trending downward, static, or not improving as quickly as you’d like, you probably have DevX problems that you haven’t yet identified.

Frequently Asked Questions

What’s the difference between UX and DevX?

User experience or UX focuses on the end-users of software, while developer experience (DevX) is about the specific experience of developers using development tooling and processes to create and maintain software. You can think of DevX as the user experience of developers using your development platform—including tooling, systems, documentation, etc.—to build software.

What makes a good developer experience?

The best DevX stems from offering well-documented tooling and processes that work well individually and are integrated as part of a development platform that enables developers to write code without a lot of manual effort to find and configure tooling and infrastructure and without constantly troubleshooting issues that don’t relate directly to coding.

Why should I care about developer experience?

Good developers are a limited resource. A good DevX helps ensure your development team is maximally productive. A bad DevX causes developers to waste time trying to make tools and processes fit their needs. This can lead to unhappy developers and turnover.