How to Prioritize the Developer Experience and Improve Output

Looking at where major DevOps trends are headed, a common theme across many tools and practices is improving the Developer Experience. One paradigm of thinking is that if you improve your internal customer experience, then your external customers will benefit too. However, up until now, the Developer Experience has been quite siloed and segregated — for a multitude of reasons, such as scaling or having best-of-breed technologies to support individual concerns. 

What Is the Developer Experience (DX)?

Developer Experience (DX) is the overall interactions and feelings that the developer feels when working towards a goal. It is similar to the definition of User Experience (UX), except in this case the primary user is a software engineer. The core definition of UX is how a user interacts and experiences a product, system, or service — focusing on perceptions of utility, ease of use, and efficiency. User Experience focuses on improving customer satisfaction and loyalty. Developers, however, are internal customers, rather than the external customers that traditional UX targets. 

With the consumerization of enterprise IT, the expectation for users of enterprise systems continues to rise, because of their experiences outside of the enterprise. Seen as highly technical when compared to an average business system user, the developer experience can sometimes take a back seat because of a stigma that “developers can just figure it out” and should be able to string together disparate open source projects even though it’s not their expertise. Even providing an API or interfaces for developers to use without explanation and education can hamper DX. Having poor DX is a detriment to overall engineering efficiency, and the ability to innovate and iterate, while not adding to technical debt. 

Pillars of Developer Experience

Similar to User Experience, there can be multiple objective and subjective measures of Developer Experience. Focusing on the three pillars of user experience — usability, findability, and credibility — are also excellent markers of measuring Developer Experience. 

Usability

Usability is how easy your software or service is to use. It answers the question, “Would a first-time user of your platform be able to achieve their goal?” Also, usability is about removing barriers. For example, unnecessary steps. Measuring usability for internal customers might be a little more challenging if the frameworks that are in place for UX for external customers are not there. Surveys are a good way of gathering feedback and also, if possible, using remote usability tests such as heat-mapping and tracking tools to measure interaction and drop-off. 

Findability

Findability is how easy or quickly a user of your software or service can find the functionality they are looking for. Having logical, contextual, and concise search and navigation features are important. Supporting the user journey across their changing tasks alludes to good findability. Similar to measuring usability, asking users what they think or having the ability to record times and use heatmaps of what is being clicked on, or where frustration starts, are all good steps. 

Credibility 

Credibility is that your users trust your software or service to solve their problems. Credibility is a long-term pillar, not only for today’s needs but for tomorrow’s needs also. The changing landscape of developer technology does make this hard to keep up. For DX, having a service that offers reliability and stability, is not hampered by downtime, and is performant  — with adequate resources  — is key to credibility. Meeting the scaling needs of the wide swath of technologies that internal customers use can be challenging. Continued adoption of your software or service — consistency — is a key measure of credibility.  

One pitfall to avoid is just focusing on the output first. For example, observability in the manufacturing world infers that if the output is good, the internal states are good too. If your team or organization is producing a lot and has good collaboration, then the experience of developers must be good. The truth is, that’s not necessarily the case — high production might be one indicator, but there might also be high toil or high burn. The expertise, staff, and overhead costs are high to produce large amounts of artifacts. 

Good Developer Experience will lead to more efficient, and thus more highly productive teams. Looking at the four key metrics from Accelerate (deployment frequency, lead time for changes, MTTR, and change failure rate) can all improve DX.  

Examples of Good Developer Experience

Good Developer Experience supports innovation, iteration, safety, and velocity. Great developer experience allows developers to focus on and experiment with what is important — and not pick up technical debt with non-functional or application operational concerns (such as scaling and robustness) along the way. Software is a team sport. Allowing for quick integration and deployment of changes, to get them into the hands of the end users, is the goal of software engineering.  

Two of the biggest detriments of DX are context switching and decision fatigue. Imagine a customer service representative at an airline having a high volume of complex issues, switching between multiple systems, and reaching out to different departments for answers or expertise — that can drive up resolution time (an example of context switching). The need to constantly make decisions and negotiate can also lead to decision fatigue. Ironically, software engineers face similar dilemmas navigating the end of their workstreams — e.g. heading to production and supporting production. 

Because of competing priorities and deadlines, software developers are great at finding the path of least resistance — so technical debt can accrue if they’re not careful. Reducing context switching and decision fatigue for developers, by having highly usable and credible software and platforms, makes for a great DX. 

Comparing StackOverflow Developer Survey results over the last few years, an interesting trend appears. In today’s market, it is not normal for someone to work their entire career on one project or at one firm. The amount of time that developers are on projects is decreasing, and the amount of time that it takes developers to be productive members of the team (ramping up time) is increasing. Developer Experience is key to building and maintaining the next generation of software and platforms. Good DX will help reduce ramp up and onboarding times and assist in the ultimate goal: getting ideas to production in the long run. 

How Harness Tries to Improve Developer Experience

The Harness Platform offers all of these pillars — and more — to help drive a positive Developer Experience from idea to production, and support as many of those iterative cycles to match the speed of development. Developer Experience is key to building and maintaining the next generation of software and platforms. As technology proliferates our lives, your external customers do not care how features reach production. 

However, your internal customers are the source of those features and improving their experience will improve and nurture the innovation pipeline. Even tasks that are seen as less than fun (e.g. going through a workflow to remedy bugs), a good Developer Experience can improve engagement. As engineers in industry continue to move around to increase their skill and craft, having engineers become more productive in a shorter period of time fosters a culture of learning and innovation. Make sure to check out our eBook, which dives deeply into these topics and learn how to provide the best DX possible.