Xplore More, Debug Less
The DevX Chronicle
What is DevX
Defining DevX very outcome-oriented I would describe it as: how easy or difficult it is for a developer to perform essential tasks needed to implement a change. These tasks can be around building, testing, starting, or debugging.
On a softer note, DevX cares about the developer experience of using a product, its libs, SDKs, documentation, frameworks, open-source solutions, general tools, APIs, etc. It refers to the systems, technology, process, and even culture that influence the effectiveness of software development. It looks at all components of a developer’s ecosystem and asks how they are contributing to developer productivity, satisfaction, and operational impact.
It is not as widespread yet as its brother UX (User Experience). The range of what DevX can mean depending on the context it is used in can be from the UX of a single product, when the U is a Dev, to also of a whole set-up in the context of a Dev team.
DevX is a rather new phenomenon. It was driven by the steep rise in available tooling for developers over the last 5-10 years, leading to great innovation and simplification but also to complicated and overwhelming stacks (read my series on why the dev stack is so complicated here).
Why should you care about DevX?
DevX aims to make devs happier :) Reason enough?
It does so by opting to:
i) maximize the amount of time engineers spend on writing code and
ii) minimize the amount of time spent on manual setups and configurations, as well as on regressions and new defects.
The positive impact often reported from good DevX includes:
increased velocity: more time spent on value-add activities
improved quality: when it’s easy to debug & test, people will do more of it
easier onboarding and adoption
Results of a Forrester survey on DevX reveal further interesting learnings on the impact of good DevX:
74% of survey respondents said they can drive developer productivity
77% can shorten the time to market
85% can impact revenue growth
75% can better attract and retain customers
82% can increase customer satisfaction
This broad range of benefits shows that DevX is not a mere tool to improve efficiency and thus impact your bottom line, it’s also a driver for top-line growth and impacts the perception your customers have, and simply overall organizational success.
On the other side of all these great advantages of great DevX, bad DevX (and many experiences today are still bad if not traumatic) can lead to products being outright rejected by the market. (read here on why Devs are such a hard customer group to crack)
How can good DevX be measured?
Should DevX be measured? While it surely is subjective to a certain degree, I do believe DevX will impact more long-term oriented KPIs such as customer/dev satisfaction, net promoter score, churn & retention, and more. So it is wise to also think about how to measure more imminent metrics.
While there is no set of standard metrics defined for DevX I am aware of, the DORA framework can be a good start:
Deployment frequency (DF): by removing hurdles good DevX improves how frequently an organization releases new software (or even allows on-demand, multiple deploys per day)
Lead time for changes (LT): through tooling and higher-level config good DevX reduces the time taken from when a change is requested or initiated to when it is deployed (ideally to less than a day)
Mean time to recovery (MTTR): through clear insights and a high level of transparency good DevX shortens the average time it takes to recover from a failure (ideally to less than one hour)
Change failure rate (CFR): by allowing for faster code review speed and reducing other DevOps bottlenecks, good DevX reduces the percentage of changes that result in a failure (ideally to <15%)
Other metrics outside of the DORA framework, slightly more holistic but also harder to define clearly, could be i) Time to First E2E Result, or ii) Time to First Commit. So low to no friction is what matters in measuring.
Additionally, how developers subjectively feel makes all the difference—which can be gauged by user testing, surveys, and feedback
I also like GitHub’s DevX formula below. It takes into account:
Productivity: how quickly or simply a change can be made to a codebase
Impact: how frictionless it is to move from idea to production
Satisfaction: how the environment, workflows, and tools affect developer happiness
I find it charming how the formula incorporates both the quantitative and qualitative side of things mentioned before but also the factor of team collaboration (C) as a multiplier to the whole equation.
How to ensure good DevX?
The X nowadays is no longer just layout and CSS - it’s nowadays much more oriented to the user’s journey, touch-points, pain points, and how to help the user solve a problem in a better way. It is thus also as much cultural as it is about other things. A good start is to nominate a DevX champion. The champion’s role will be to hold the team accountable and actively seek opportunities to improve DevX.
Other quick fixes to implement good DevX in your team can be to create good onboarding guides, standardize essential tasks, use observability as much as possible, minimize the number of repos, minimize remote dependencies for local development, heavy collaboration efforts, emphasize speed and short feedback loops and implement high degrees of automation and integration for low levels of friction or toil. And last but not least transparent and well-documented processes
Who is doing it really well?
Having laid the foundation with this piece, in the next step, I’ll look into a few companies that have perfected DevX and made it an integral part of their own engineering culture and their products. If you have any recommendations from personal experience - let me know!