The topic of Developer Experience (DX) has entered the spotlight as the demand for talent continues to soar and technical teams look for ways to optimize the way they work.
In this webinar Rachel Stephens from RedMonk, the developer-focused analyst firm, and Diffblue’s CEO Mathew Lodge discuss why the question of great DX has come so sharply into focus amongst companies including RedMonk’s clients, the different ways companies are addressing the issue, and the key role automation can play in helping both technical teams and IT leaders.
In this webinar we cover
The Concept and Evolving Importance of Developer Experience (DX)
Definition of Developer Experience:
Developer experience as analogous to user experience (UX), but specifically for individuals who create software. It encompasses “all of the different touch points and interaction points for someone using a product, but in this case the users specifically are people who are creating software, so software developers.” Key facets include:
- Functionality and Ease of Use: How effective and efficient a tool is to use.
- Discoverability and Intuitiveness: How easily developers can understand and utilize tool components.
- Contextual Information: Providing enough context without being overly verbose or requiring extensive log sorting.
- Thoughtful Design: Smoothing out potential points of friction for developers.
The overarching goal of DX is to “position developers to do their best work,” enabling them to “do what they want to be doing and to to to do their very best work in the day.”
Historical Context and Modern Relevance:
Developer experience is “not really a new concept,” what has changed is the “much more important” role of software in modern organizations. As software “is eating the world,” there is “vastly more software to be written than there are people to do it.” This scarcity of developers makes DX a “much higher up their priority list” for organizations, as they are concerned about “how do they recruit and retain development teams” and make them as productive and satisfied as possible.
The Developer Experience Gap and Integration:
Individual tools might optimize their specific part of the toolchain, but the challenge lies in “thinking about how all of the tools fit together and integrate.” Modern software is built in a “much more composable way,” with more modular components from various internal and external sources. This necessitates a focus on “those integration points and the potential frictions of those integration points in order to have successful developer experience.”
Drivers for DX Focus:
Beyond the sheer volume of software and developer scarcity, other drivers include:
- Skills Gaps: Especially in emerging technologies like Kubernetes, there aren’t enough skilled professionals.
- Upskilling: Teams are constantly needing to learn new technologies.
- “Doing More with Less”: Companies are asking their teams to increase output with stagnant or fewer resources, making automation and effectiveness crucial.
2. Organizational Approaches to Improving DX
Organizations are taking various actions to address DX challenges, broadly categorized into two approaches:
a. Platform-Centric Approaches:
- “Heroku the dream”: Companies seek “this easy way to get their software out the door” and “fewer things that they’re trying to string together.”
- Limited Platforms: Examples like Netlify or Render offer simplified integration for specific use cases. The aim is to “kind of tackle a limited use case, but it’s not going to be something that works for every class of application, but can make it easier to integrate all of these pieces into the platform.”
b. “Golden Path” / Paved Road Approaches:
- Spotify-esque Model: Organizations establish an “opinionated scaffolding that we’ve assembled internally.”
- Internal Tools & Platform Teams: If developers use these supported internal tools, it “will help you get your application into production in our systems.” Using different tools is permitted but requires self-support.
- Common Goal: In both approaches, the commonality is “trying to reduce the friction for people to get their tools into production and their applications into production.”
3. The Central Role of Automation and Tooling in DX
Shaping Culture and Productivity:
Automation helps “smooth the path” by making the desired actions (like using a “golden path”) “the easiest thing for you to do as a developer.” If tooling “gets in the way” or “doesn’t help your people get done what they need to get done then it’s not improving your developer productivity.” Tools and culture are “equal sides of the same problem,” and attempting to implement cultural changes without supporting tools will lead to “a path of sadness.”
Addressing Tedious and Error-Prone Tasks:
Software development is uniquely “100% manual,” which is “insane” compared to other industries. A significant opportunity for DX improvement lies in automating “tedious and error-prone” tasks. Tedious tasks lead to more mistakes, creating an opportunity for automation to enhance the developer experience.
Characteristics of Good DX Tooling:
Key characteristics for tooling that supports good DX:
- Reducing Tedium and Easy On-Ramps: Quick setup, scaffolding, frameworks, templates, and general automation.
- Context: Allowing developers to understand system behavior without context switching or breaking flow state.
- Short Feedback Loops: Providing immediate feedback on code changes (“is this working?”).
- Documentation: High-quality documentation acts as “marketing material for your developer,” enabling self-service and troubleshooting.
4. Unit Testing as a Prime Example for DX Improvement
Analogy to Manufacturing Production Lines:
Matthew Lodge draws an analogy between modern software pipelines (CI/CD) and manufacturing production lines. “Traditional QA” at the end of the line is inefficient. Just as lean production principles advocate for finding problems early, “unit testing is essentially that analogy; it’s like how do you find problems at the time the code is being written.”
Developer Perspective on Unit Testing:
Despite its importance, unit testing is often seen as a burden. Rachel Stevens states that “25% of Java developer time is spent on writing unit tests, and in reality, I think that’s very conservative.” Furthermore, “around 40 to 50%… of developers would prefer to never write a unit test again.” This makes automated unit test writing a “good example” of how automation can improve developer experience.
5. Diffblue Cover: Automating Unit Test Generation
How Diffblue Cover Works:
Diffblue Cover is a product that “writes software that writes software,” specifically unit tests for Java code.
- AI-Powered Test Generation: It uses “artificial intelligence, it’s machine learning,” specifically “reinforcement learning,” a technique similar to Google’s AlphaGo. This approach involves a “probabilistic search” of the immense “test program space.”
- Iterative Test Generation: Diffblue Cover writes a test, runs it, assesses its effectiveness (e.g., coverage), predicts a better test, and iterates until the optimal set of tests is found.
- Baseline Creation: It writes “a baseline of tests” reflecting the “current behavior of the application.”
- Regression Detection: These tests are run against “proposed changes” to find regressions during development.
- Incremental Updates: After a pull request is approved and merged, Diffblue Cover “automatically update[s] that test Baseline to to match the new code.” It focuses on tests “impacted by the change.”
Integration into Development Workflow:
Diffblue Cover integrates into typical CI/CD workflows:
- Developer creates a pull request.
- In the CI system, existing tests (and Diffblue tests) are run against the change.
- Diffblue tests help “catch more aggressions.”
- After PR approval and merge, Diffblue updates the test baseline.
Key Benefits and Features:
- Speed: Diffblue Cover can write a test “roughly about every two and a half seconds.”
- Idiomatic Code: Tests are “designed to be idiomatic for spring,” making them understandable for developers if they fail.
- Coverage Improvement: A demonstration showed Diffblue Cover increasing unit test coverage from ~25% to 71% for an open-source project.
- Identification of Untestable Code: The tool reports “some of this code is not testable.”
- Code Refactoring for Testability: Diffblue Cover can “refactor your code to make it more testable” and “fix it for you,” then re-run to generate more tests.
- Local Execution: The tool runs locally on the developer’s machine (Linux, Windows, Mac).
- Autonomous Operation: Unlike tools like GitHub Copilot (which provides auto-completion and requires human review), Diffblue Cover is “100% autonomous and developer does not need to do anything” with “tests are guaranteed to be correct.”
- CI/CD Integration: The command-line tool is designed for seamless integration into CI/CD pipelines, including incremental test writing based on code diffs.
6. Business Outcomes and Measurability of DX
Tangible Benefits:
While direct causal links between DX and revenue can be complex to measure precisely, there are clear benefits:
- Velocity: Good DX enables developers to “build effective and great software more quickly.”
- Top-Line Revenue & Value Creation: Software has shifted from being a “cost center to something that is driving kind of Topline Revenue value creation.”
- Competitiveness: Senior executives “can directly connect the happiness and the… churn on their team… to business success and the effect on competitiveness.” Low-churn teams that deliver “good software… quickly” are seen as vital.
- Focus on Value-Add: DX helps teams “focus more effort on the things that really deliver value for the business,” reducing time spent on non-core, tedious tasks that management might not fully understand. Jeff Lawson’s quote from “Ask Your Developer” is cited: moving from a “build versus buy” mentality to “build versus die.”
Measurability:
While “Dora metrics” offer solid engineering-centric measurements, correlating DX directly to revenue is “a little bit less clear.” However, there are “strong correlations between good engineering teams and those business outcomes.”
