Developer experience (DX or DevEx) is the quality of a developer’s experience while building, testing, deploying, and supporting software. It includes tools and technologies, but also processes, workflows, access to resources, and the time spent waiting for help. Good DX removes work that does not contribute to product improvements, giving teams more room to discover user needs and deliver solutions. section 13.1 section 13.0
DX matters when teams are expected to deploy and support their own applications. Responsibility without an easy way to do those jobs can slow them down. An internal developer platform (IDP) can help, but technology alone is not the goal: platform decisions should be judged by how well they improve the experience of the teams using them. section 13.0 section 13.1
Look for friction across the development lifecycle:
- Starting work: Can a team create an application and obtain the tools, knowledge, and resources it needs without avoidable delays? section 13.1.4 section 13.6
- Delivering changes: Are build and deployment capabilities easy to use without waiting for another team to provision infrastructure or grant routine access? section 13.1.2
- Running software: Do teams have practical ways to support applications in production, including metrics, monitoring, logging, and observability? section 13.6
Self-service in practice
At HMRC in 2015, an internal platform let roughly 60 development teams start new services and deliver improvements daily. A self-service Jenkins job created a Git repository containing an application skeleton; a few lines of configuration set up pipelines, metrics, monitoring, and logging. The point was not the particular tools, but how little coordination a team needed to begin delivering. section 13.1.5
When complexity moves to developers
At one Austrian company, platform responsibilities were complex enough that each team needed a dedicated member to handle Kubernetes configuration files and Git repositories. That is a warning sign: a platform can add work even while offering more technology. section 13.1
Improving DX is an ongoing product decision, not necessarily a mandate to build a large platform. Capabilities might be offered through a UI, CLI, YAML, or GitOps workflow; existing offerings can also be curated rather than rebuilt. Seek feedback from development teams, and check that reducing their cognitive load does not simply transfer it to platform engineers. section 13.2 section 13.4.3 section 13.4.5
