I’ve been thinking a lot about developer experience lately, because I’ve been scaling up a team of developers to tackle new projects. This is an excerpt of something I wrote recently for assemblyhq.com.
Companies that invest in delivering good developer experience can see revenue grow four to five times faster than those who don’t. This may seem like a lofty assertion, but it makes intuitive sense when you consider what gets better with good DX:
- Velocity: Features are delivered faster when there is less context-switching and earlier detection of code problems.
- Quality: Final products have fewer defects and increased stability.
- Visibility: Higher confidence from all stakeholders that the development effort is focused and effective.
- Recruiting and onboarding: Attracting and training good developers is faster and cheaper.
- Employee engagement: Developers are personally invested in the work because they can clearly see how they are contributing to a reliable, performant, high-quality product. Conversely, unhappy employees can cost an organization approximately 3,400 for every $10,000 of salary in the form of missed workdays, and decreased productivity.
- Cost savings through retention: There’s a price tag for not prioritizing engagement and retention. For each employee lost, the cost of replacing them can be anywhere from 50%–250% of their annual salary.
What does bad DX look like?
From inside the dev team, bad DX is easy to identify. You might have heard rumblings from the team that tools and codebases are scattered, incompatible, slow, and fragile. Or that new features have unpredictable side-effects and too many defects. In some cases, instead of shipping business-critical features at a good cadence, more than 40% of a typical developer’s workweek might consist of struggling with these issues.
But what does bad DX look like from outside of the dev team? If you are in a leadership or stakeholder position, here are some tell-tale signs to watch for:
- Poor visibility into the day-to-day development process
- Little sense of ownership or engagement
- Black-box budgets
- Reluctance and uncertainty in the face of new business requirements
What does good DX look like?
From inside the dev team, good DX is hard to spot - because it is virtually invisible. Tools behave as expected, code is light on boilerplate and dense with business logic. Builds and deployments are so fast and effortless that the developer does not need to think about them.
From a leadership or stakeholder position, you’ll find:
- Clear visibility into the day-to-day development process
- Budgets map cleanly to features and releases
- Higher confidence in planning and estimation efforts
- Developers can communicate about new business requirements with confidence
Application modernization delivers better DX “out of the box”
[Edit: For context, I’ve been working on modernizing a set of legacy apps for the last couple of years.]
Any application modernization strategy offers a multitude of opportunities for improved DX. Some will flow naturally from the “modern” nature of the implementation. For example:
- Well-architected systems flatten learning curves and accelerate time-to-market because code tends to be expressive, readable, and easier to reason about.
- A reliable cloud-based CI/CD pipeline will reduce a daily source of friction for developers accustomed to a slow and unpredictable deployment setup.
- Implementing new features in a stable, performant and robust software system requires less context switching. This allows developers to maintain the flow state in which they do their best work.
- Predictable, well-documented modern solutions lead to confident coding with less anxiety about unintended side-effects and regression issues.
That’s it! I hope you find this helpful as you think about how you can assess and improve your team’s developer experience.