Many words have been written over the last couple of years about the importance of Developer Experience. And that’s for good reason. If your organization writes software, developer experience is affecting your business—for better or worse.
I worked for over 20 years as a developer at a large software vendor, where it was taken for granted that developers needed the right tools and environment to get their work done. But over the last few years as a consultant at VMware Tanzu Labs (formerly Pivotal Labs), I’ve collaborated with many enterprises whose business depends completely on software, yet they fail to prioritize developer experience the way that a software vendor does.
The examples in this article are based directly on the things I’ve seen in enterprises that are frustrating their developers and making it hard for them to deliver. And I’ll offer some advice—from a developer’s perspective—about how to create a developer experience that can help drive innovation.
Why focus on developer experience
Developer experience (DevX) can be defined as measuring how effectively a developer can obtain and interact with the resources needed to build, maintain, and deploy software. Developer experience has a direct impact on the ability to get ideas into production. Bad developer experience means that the business can’t respond quickly to changing market requirements; it takes longer to launch new products and longer to fix issues that customers care about. Bad developer experience can hurt your ability to generate revenue. For evidence of this, see Forrester’s checklist linking good developer experience to business growth.
DevX also has an indirect impact on staff retention. If your developers are frustrated by bureaucracy and inefficient processes, they are more likely to leave, and hiring new employees is always more expensive than retaining the ones you already have.
This article is a brief examination of what good and bad developer experience looks like, drawn from examples seen in real enterprises. I’ve split developer experience into two categories: individual developer experience, which covers how a developer can set up their own environment and workstation, and team developer experience, which covers wider issues about how a team can be set up for success.
Individual developer experience
Enabling your developers to be productive with the right hardware and software is the first step to making development teams productive. Make it easy for developers to do the right thing, because overly bureaucratic processes impede progress, and people will find ways to circumvent them.
Developer hardware and operating systems
For good security reasons, many enterprises do not grant users administrator privilege on their work computers. However, developers have different requirements from most users, and they frequently need to install new software, and run processes that require higher-level privileges (for example, debuggers). If the only way a developer can get those privileges on their local workstation is to raise a ticket and wait, they will spend more time waiting than they do developing.
To address this, provide developers with an easy way to unlock administrator rights. And make it easy for those developers to know what they should—and should not—install (more about this in the Developer setup and onboarding section below).
Developers also need more powerful workstations than most users. Integrated development environments (IDEs) are resource hungry, and debugging a large application is even more demanding. The minimum amount of memory for a developer laptop in 2023 is 16GB, and 32GB is more appropriate, particularly if they need to run container images locally. If your developers are working on projects for deployment on Kubernetes, having a machine powerful enough to run lightweight implementations like Minikube makes learning and experimentation much easier.
Of course, you could save $1,000 by giving a developer a lower-specced machine, but it might halve their productivity. How does that $1,000 look offset against six months’ wages?
If your developers use Windows machines, virtualization features should be enabled, and it should be possible to use the Windows System for Linux 2 (WSL 2). A lot of modern development tooling is easier to run on Linux, and some tools are only available on Linux.
Work environment
It's hard to be prescriptive about ideal work environments, especially when so many developers work from home these days. But there are a few principal requirements. The first is a reasonably quiet environment. Lots of distracting noises or loud conversations make it hard to concentrate.
Where teams employ pair programming, there will be more discussion than in teams of solo programmers. But the ambient environment still needs to be quiet enough that people don't have to raise their voices, so that pairs can work without disturbing others nearby.
Programmers (whether they’re solo or paired) also need to be able to spend time on programming without external interruptions. Constant interruptions to answer questions, provide status updates, or attend too many meetings during the day all reduce productivity. Teams should aim to finish the daily standup in 10 minutes. If some team members have blockers or other issues that need more time, discuss those after standup so that anyone not directly involved can leave.
Developer setup and onboarding
Imagine a developer starts at your organization, either as a new employee or as a contractor. They get a new laptop from IT. How long does it take them to install the tools they need?
At a minimum, any developer will need a working compile and runtime environment for the programming languages they will use, an IDE, a version control client, access to your version control repository, and access to the systems you use for tracking work and managing bugs.
How do they know what to install and where to find it? From best to worst, the options look like this:
-
They are sent a script that automates the baseline setup for developers at your organization. You can automate this on MacOS using scripts that run Homebrew (`brew`). On Windows, create a batch or powershell script using `chocolatey` to install dependencies.
-
There is an easy-to-find document explaining what they should install and where to find it. The document clearly states when it was last updated and has an easily accessible revision history.
-
They must work it out for themselves. The application they are working on is written in Java 11. The developer portal doesn’t tell them whether they are licensed to use the Oracle JDK or whether they should install a distribution of AdoptOpenJDK.
Make it easy for developers to do the right thing when they start out.
Team developer experience
In this section, we’ll examine the experience of developing a new application and getting it into production. Let’s introduce a hypothetical example to illustrate potential problems.
A mortgage lender currently provides a traditional brokerage-based service for new mortgages. Their service is supported by software that was originally built 25 years ago and is still under active support and development. The lender wants to take part in a newer, web-based marketplace where they will compete directly with other lenders. A borrower enters their details into the mortgage marketplace website and gets a list of offers from different lenders (similar to the online marketplaces for things like insurance).
To take part, the lender must provide an API that will enable the return of mortgage quotes. The API must respond within three seconds or the results will be ignored. The lender can use the marketplace test environment to ensure their implementation works as expected.
Deployment platform
We'll assume the lender has decided to use a Kubernetes cluster as their deployment platform, and the mortgage application will scale horizontally to meet demand peaks. The development team has a set of milestones to meet, including first alpha version, beta running against the marketplace test platform, and finally, v1.0 in production.
To get started, the team needs at least the following resources:
-
Access to a development Kubernetes cluster to run the application as they build it
-
Access from the development cluster to a test or development version of the existing mortgage application
-
An image repository for container images for the application
-
A continuous integration and continuous deployment (CI/CD) pipeline for the new project
-
Services like databases, message queues, and API gateways available in the development cluster
-
Access to a test or staging cluster to run and test stable versions of the new application. The staging cluster needs the same services and access to other systems as the development cluster.
What happens next? Ideally the team lead fills in an online request for development cluster access. It might be a namespace in an existing cluster or a new cluster provisioned on demand. The resources are available within an hour of making the request. Team members get invites to access the cluster, and everyone has their own set of credentials within a day. Access to the upstream test/staging system might take a little longer, but it should still be available within a couple of days.
In many organizations, access to a development platform is not straightforward. For example:
-
You have to fill out a ticket requesting platform access. This goes through several levels of approval before provisioning starts.
-
Once approved, provisioning is largely manual. It takes a week from original request to platform access.
-
There has to be a separate ticket to get credentials for each developer. This is also manual. Same-day turnaround is possible but unusual.
-
Access to the upstream test system is also a manual process. As well as requesting credentials for upstream system access, the developers also have to raise separate tickets for firewall changes so they can actually reach the upstream system over the network.
The application being developed needs other services, including a database and a message queue. Is creating these self-service, or does the development team need to raise more tickets? When they raise tickets, do they have to answer detailed questions about capacity and traffic that they can’t yet answer? Time spent filling in forms with hard-to-answer questions is time not being spent on developing applications the business needs.
Continuous integration and continuous deployment
Teams can deliver much faster when they have a continuous integration and continuous deployment (CI/CD) pipeline. Are the resources for this easily available? For example, if the organization uses GitLab CI/CD pipelines, is it easy to access runners to run the pipeline? What if your build requires an environment that isn’t available on the default runners available? How easy is it for the team to get resources to set up their own runners?
What does good developer experience look like?
You need to balance two priorities to provide good DevX:
-
Enable individuals and teams to access the resources they need quickly and easily
-
Keep the organization’s systems and data secure
It might seem that those two things are in conflict, but cumbersome processes also hinder security because they motivate employees to find workarounds for those processes just so they can do their job. Here are some tips for designing a developer experience that meets both of these needs:
-
Don't treat development environments exactly like production. Development environments need to enable experimentation, so it must be easy to deploy applications, create resources like databases, connect to upstream and downstream applications (as long as they are also development or test deployments), and get onboarded. You can make the rules stricter for deployment environments that are closer to production environments (for example, a staging environment might have very similar rules to the production environment).
-
If you can experiment easily in development, you can iterate faster to solutions that will be successful in production, and you can discard approaches that don’t work or won’t scale well early on.
-
Foster a “platform as a product” mindset in your operations teams (more about this below).
-
Each developer should have their own unique credentials for accessing deployment environments. Automated processes (for example CI/CD pipelines) should also have their own unique credentials and not reuse the credentials of an individual employee.
-
Automate what you can, and then make it self-service, for example, creation of resources like databases.
-
Audit automated processes so that you can see requests after the fact.
-
Developer portals can be transformational in helping developers (see this Gartner report showing how portals can assist developers and improve compliance), but they will only be really successful as part of a strategy that includes other internal sources of information and documentation. Simply adding a developer portal alongside existing Confluence and/or Sharepoint resources will just add to confusion.
Platform as a product
Platforms are where applications are deployed. Over the last two decades, the industry has moved from deploying applications directly onto hardware through deploying to virtual machines and now containers. This has enabled flexible scaling, more efficient use of hardware, and better deployment automation, but it has also brought greater complexity.
A well-designed, well-managed platform makes that complexity easy to understand and manage. The ops teams who manage your platforms have several demanding groups of customers: the developers creating the applications that run on them, InfoSec staff who have to keep data safe, the business that requires reliability and scalability at reasonable cost.
Treating your platform as a product means considering the needs of these different groups when designing and running your platforms. It enables the ops team to make it a priority to delight developers. This in turn means the developers want to use the platform, rather than being driven reluctantly to it or looking for better alternatives. The alternatives often being that a team would rather manage their own AWS, Azure, or GCP account than use the corporate platform. Once this happens, you have less oversight over what the team is doing and you will not get the scale of usage on the corporate platform that provides a good return on the investment. You can read a good white paper discussing platform as a product here.
Balancing security requirements with the freedom of action required for good DevX is not easy. However, the effort of making staff happier and more productive leads to more agile and innovative organizations.
Want to learn even more? Read about seven ways organizations can turn developer experience into a competitive advantage. And read this executive checklist from Forrester explaining how to foster a strong developer experience for business growth.
