The “developer experience” (DX) describes how engineers feel about working with a system. It applies the notion of user experience (UX) to software engineering. A good experience helps developers to be productive with minimal frustration, while a bad experience leads to protracted development and unhappy engineers.

This idea is often applied to the design of products, especially those that are likely to be selected and used by engineering teams. It can also be applied to a much wider, organisational context. An organisation should seek to establish a technology environment and engineering culture that developers want to work in. Architecture has a key role to play in this by virtue of its role in helping to shape the technology landscape.

The business case for developer experience

System design is often a trade-off between different interest groups, such as customers, support teams, salesmen, product managers, and engineers. Development interests can be overlooked in the stampede to deliver new features, but consistently failing to take these concerns into account will have a negative impact on productivity.

Some recent research by McKinsey framed this in terms of what they called “Developer Velocity”. They found a strong correlation between business performance indicators such as shareholder returns, operating margins, and customer satisfaction with commonly identified features of a well evolved engineering culture. These features included a combination of engineering practices, technology choices and organisational enablement.

Many of these findings have been echoed elsewhere. In "Accelerate" Nicole Fosgren et. al. attempted to define high performing engineering teams and identify the practices that they had in common. They describe a series of capabilities that include developer autonomy, a significant investment in automation, loosely coupled architecture, and a supportive management culture.

There are some common themes in these studies. They can be described in terms of fostering the kind of conditions that allow talented engineers to build applications without impediments. Architecture should play a lead role in establishing these conditions by empowering engineers, ensuring the right technical context, and contributing to a healthy engineering culture.

Accessible architecture

You should think about an architecture in terms of creating a platform that developers will use to build applications. An external audience would expect a set of tools, libraries, guides, and documentation to be in place to make the platform easier to engage with. Why shouldn't an internal audience expect the same?

Producing comprehensive SDK documentation for your internal architecture is a good discipline. It forces you to think in terms of how developers will engage with the wider infrastructure.

You should also look to establish a consistent “house style” based on standards, protocols and idioms that will be familiar to teams. Follow industry standards where you can and avoid unnecessary acronyms or invented language.

Engineers should choose their own tools. Most of the time.

A mature engineering culture trusts teams to choose their own tools. This does make sense from an engineering perspective. If you want an experienced team of engineers to perform well then it follows that they should be able to choose the most appropriate tools for the job.

This does need some clarification as there is a trade-off between the needs of the business and the freedom of individual teams. If teams are given carte blanche then organisational efficiency may suffer if there are too many competing tools in play. Standardisation can benefit an organisation by focusing investment and encouraging a concentration of expertise.

Clearly there needs to be a balance here. In my experience, there is a strong argument for asserting a common approach to how services are deployed and monitored. This is especially true in a distributed, microservice environment, unless the organisation is operating a "you build it, you run it" approach. There is also a case for standardising on the “rules of the road”, or the interfaces and protocols used in service collaboration.

Beyond that, tool choices should be a team concern. A rule of thumb could be that engineers are free to make decisions that only directly affect their team. This implies a common approach for shared concerns such as deployment and monitoring while leaving latitude in determining how applications are built.

Using modern technologies

It goes without saying that engineers are strongly motivated to use the latest kit. This is more than just CV-driven development, as modern cloud-based frameworks and tooling allow teams to be more productive. Less time is spent on managing environments or automating code production as these are regarded as solved problems in more modern development stacks.

Added to this is the inevitable grind of technical debt accumulation. Over time, a system's design becomes increasingly out of step with the business processes is should be implementing. Left unchecked, this will undermine a code base as certainly as any obsolete technology.

Despite this, many business-orientated stakeholders are tolerant of dated technology. This is largely because they do not have to engage with it directly. The costs of dated technologies are hidden from them. They do not have to watch their careers disappearing down a drain of deprecated frameworks and dated components. Their day-to-day work is not being undermined by manual processes or byzantine code.

A constant battle should be waged against software entropy. Component versions should be kept up to date. Refactoring should be an assumed part of any feature development. All this requires a willingness to invest in the ongoing health of a code base at the expense of new features.

Culture and psychological safety

A recent Google research paper surveyed developers to determine which factors had the most impact on developer productivity. It found that non-technical factors such as decision-making autonomy, mutual respect, and job enthusiasm had the strongest correlation with self-rated productivity.

These results suggest that developers are not just in it for the technology. They want the freedom to be able to make decisions, have their ideas taken seriously, and receive useful feedback. They want to work in a mutually supportive group whose work they can respect.

This requires a culture that provides developers with some degree of psychological safety. There needs to be a shared belief that you can make mistakes and that some degree of risk-taking is permitted. This can be facilitated by engineering practices such as feature flags and automated rollbacks which support rapid iterative development and help to lessen the impact of failure.

It also requires a collaborative spirit that encourages engineers to contribute ideas. Forming communities of practice can help to give a voice to engineers, foster greater collaboration across teams and recognise the importance of engineering as a discipline.

Where does architecture fit in?

Architects have a key role in setting the direction of travel for development. This gives architects an opportunity to help establish the conditions that foster a good developer experience.

Any architecture practice should recognise the right of engineering teams to select their own tools, generate their own ideas, and design their own solutions. Architects should be helping teams to win support for technically driven work, acting as an advocate for the developer experience in determining development priorities.

Architecture can also create an environment that is empowering for developers. A loosely coupled architecture gives teams greater autonomy in building solutions and making decisions. Teams should be encouraged to adopt new technologies and engineering practices and given more latitude to experiment. Architects can also play a role in fostering a collaborative spirit between development teams by acting as a conduit between potential silos.

Above all, architects have a role in setting the tone for development. They can ensure that an architecture is accessible to developers by promoting simplicity and ensuring clarity.

Filed under Agile and Development process.