The value of developer experience and how the concept connects a variety of important techniques

A focus on good developer experience (DX) as an essential enabler for agile, high quality and fast development has only quite recently risen as an important perspective. Naturally many people have recognized it as essential for quite a while but the branding of "developer experience" drawing on the more widely understood concept of user experience is fresh - and fitting.

Perhaps one reason for the rise of the concept of developer experience is the increasing burden of complexity being placed on the average developer. When you think about devops, GitOps, NoOps, agile cross-functional teams, full-stack development etc. a good developer increasingly has to master a larger number of tools, techniques and layers than before. There was a good reason for highly specific roles in the traditional development model since so much of the details had to be managed manually - getting the last ounce of performance out of an Oracle cluster truly was a task for a specialized professional but I'm glad we're mostly moving past that world now. Not to say that deep specialization isn't necessary and valuable - quite the opposite - but the level of automation and abstraction (that actually makes sense and doesn't leak) has improved to a degree that NoOps (no separate ops team - dev and ops truly combined) actually is within reach with competent people.

The perspective that drives the highly functional abstraction and automation is developer experience. With that in mind the tooling can be designed so as to provide maximum ability to reason about code, architecture and everything while automating all but the truly unique and value-adding decisions. This trend ties together with everything-as-code as another important enabler of high degree of automation and visibility.

So what creates a good developer experience in somewhat more detail without going to anything technology specific?

• All repeatable tasks automated - or at the very least with clear and easy to follow point-by-point checklists
• Relevant, up-to-date and tight documentation which is visible by default
• Everything visible by default so it is easy to find our relevant information while restricting modification controls only to relevant teams on a need-only basis - but with openly available and very clear information on how to get the relevant permissions for when they're required
• Internal API ecosystem with a functional developer portal is important for integration level providing a visibility to all the systems available as services within the corporate ecosystem
• Ties in to API First principles (will create a separate post about this)
• Obviously secrets are not visible by default - but the information and practices surrounding secret management should be visible
• This also enforces the security aspect of not trying to get away with simple security-by-obfuscation
• Best practices baked into extensive and high quality reference models (of application sample projects, CI/CD pipelines, commonly repeated system architecture templates dependent on domain, etc.)
• Also documented in tight format and linked to more extensive driving requirements, compliance, regulatory etc. documentations but understanding the base material extensively should not be a requirement at developer level for secure and compliant development
• Reference models should include all common cross-cutting functionalities and non-functional requirements implemented in a default way (and included in platform (e.g. Kube) approach as often as possible). This means failover, HA capability, database usage patterns, logging approach, monitorability (highly dependent on approach), health & readiness checks, single project structure, etc.
• Make the reference models so easy to start with that that's just the most fun and quick and effortless way to start a project - that way good recommendable practices start spearing almost by themselves. It's still of course important to have good tech leads, mentors and training and the best results are produced when all of these are aligned
• Fully automated CI/CD pipeline with build-once-deploy-everywhere structure, incorporated unit and service level test automation runs, functional pull request based code reviews with minimal hassle
• Consistent and unified service authentication and authorization approach
• Depends a lot on what the internal integration service landscape looks like. Internal API ecosystem could standardize on unified OIDC / Oauth2 model and proxy legacy ESB / SOAP
• API First and high quality service API specifications
• More work for when team is providing their service but so much easier to start using other teams' services.
• Again heavy tie to internal API ecosystem and developer portal and also the consistent authentication
• Unified developer experience for different hosting platforms (on-premise / partner data centers, different cloud providers)
• Ideally you would standardize on a single platform but in many cases for larger enterprises this is not ideal or possible due to highly varying requirements of different teams and departments. Plus the untenable overhead of overtly centralized decision making. These factors, combined with enabling low cost exists from specific cloud providers, have led to the rise of multicloud strategies which can cause serious headache for DX if there isn't some common level of standardization at development platform level
• This is where Kubernetes steps in. See my previous (and upcoming) blog posts on this topic specifically
• It stays possible to reason about how any part of code or the overall architecture works, what it depends on and how it affects others
• At code level this is developer / team responsibility
• At higher level this is the responsibility of architecture guidance
• This is a very important aspect both in how easy it is to develop something new and especially when something goes wrong and needs to be analyzed and fixed quickly
• And easy-to-reason-about development is just more fun - we all know the hair-pulling feeling of not being able to figure out why it's not working and it turns out to be something extremely non-intuitive (not to saying doing away with this entirely is possible)

So far I've only talked about DX in the context of increased productivity (although it might not've been apparent from each point) but of course another, and nowadays very considerable, benefit is the higher retention of high competence developers. There is a serious shortage of highly competent developers in the market (and average or below developers (especially with attitude issues) sometimes hurt overall productivity instead of helping) and providing a good developer experience significantly increases the likelihood of both recruiting and retaining them.

Did I forget to list something important that you feel is an essential part of good DX?