How I improve the Developer Experience

Evolution of software development production

Project Management was a linear process entering the production phase with a list of requirements and very little give in the system to accommodate the difficulty of building software. Then having read up on the theory of constraints and the Toyota Production System, we came up with this fantastic idea to break the planning phase up and democratise the process. In essence, sizing the task was better when the developer could have input. As a result, though not foolproof, planning errors were reduced significantly. We call this Agile. While this renaissance in project management happened, a similar level of innovation was occurring on the technological front. With improvements to project planning and overall productivity improvements within software development teams, we began to notice wasted time and bottlenecks in software production. It manifests as frustration waiting for a build or integration stage to complete or desperation for a software development process that lacks the refinement necessary to produce a production release.

The problem with a lousy developer experience

There are no winners with a lousy developer experience because the software development production system creates the developer experience. So how do you manage code merges, tests, code quality, and releases? As a developer, complex processes, slow iterative cycles and breaks in flow state instantly impact productivity and result in feelings of frustration. There is no way to improve the developer experience without investment. There is no such thing as instant developer experience improvement or adopting any software solution to improve the developer experience. When working with third parties, in many cases, they have yet to learn what the developer experience even means. However, you are in luck because at Servana; we measure ourselves based on the great developer experiences we enable.

Good developer experiences

A good developer experience (DX) has similar outcomes to a better user experience (UX) because great developer experiences are fast, intuitive, reliable and obvious. However, it goes further because great developer experiences enable organisations to require standards in quality acceptable as part of their software development production system. These standards ensure that developers work to the same requirement level regardless of experience or time at an organisation. So, yes, a good developer experience saves a developer's time, but it also unlocks the ability to add compliance and governance to the software development production system. A good developer experience will benefit new developers, who will find everything they need in a few easy steps and be productive within hours. In addition, developer experiences go a long way to make working at your organisation more inclusive. Yes, inclusive because while you may have developers at varying levels asking for help, the process of asking for help is often not quality controlled and can impact a project.

Your software development production system

An organisation should manage the means of software development production. This process is more inclusive because the 'secrets of how you produce software' are in plain sight in a source control repository. The 'secrets of how you produce software' are encoded into the developer experience. Your software development production should include the following;

• The way you refine source code between merges or in branches?

• The way you test source code

• The standards for tests

• The way you package source code

• The standards for a release

• The way you release packages

Without a software development production system, your developers will manage the above processes independently, and the developer experience will be sub-optimal from an organisational perspective.

Improving the developer experience will help your software developers daily. Each minute you shave from the iterative development and test cycle is one more minute for another iteration. Onboard new engineers faster and get them working on new features as soon as possible. But first, does your software development production system provide a good developer experience?

Measure the quality of the developer experience based on how easy it is to onboard new developers.

Why optimise the developer experience?

Consider how difficult it is to do work when the process for doing this work is in itself complex. Creating great software requires focusing on the problem domain, not wrangling the tooling or processes to produce the software. Frustrated developers are not happy people, and with the cost of hiring software engineers going up, retaining the developers you have is even more critical. We want happy developers.

Avoiding Bottlenecks

If your software development production system or SDPS is inefficient, you will create bottlenecks, wasted time, and a terrible developer experience. Automating the developers' workflows needs to be improved to reduce the time required to make an iterative cycle. The best people to suggest these improvements are the developers themselves, as they would be the best place to decide on the improvements.

Traps for bad developer experiences

There is so much low-hanging fruit. Before I go further, I'm not going to talk about companies that manually release or do releases themselves or anything janky. I'm only focusing on organisations that need to build great software at a reasonable scale. Or organisations that want to create a software development production system and help their developers focus more on products, not servers.

Gitflow and complicated merge processes

On paper, Gitflow offers good reasons for a better process for managing source code refinement. However, Gitflow correlates poorly with good developer experiences because it creates many steps of refinement that are duplicated and add time to the development process. This stems from the simple case that you are duplicating code refinement processes in branches. 1. How many times do you need to build that code? 2. How many times do you need to test it? 3. How many times do you need to scan it? 4. How many times do you need to package and deploy it? How you answer the above questions doesn't matter because this is a self-inflicted state. For example, if you say we don't need to test software in feature branches, consider that you still need to build and package software in feature branches so a developer can test it before merging. While the promise is that Gitflow is a lower-risk code merge strategy, it is still risky. The effort level to have a five-star developer experience with Gitflow is much higher.

Flaky environments

When you need to test software, there are issues with memory and capacity in the various non-production environments that cause pipelines to fail and result in massive backlogs of software development tasks. Which compound and increase the time it takes to test or build your software.

New Developer Scenario

Imagine this scenario. A developer joins your organisation. Their first day is exciting; they arrive on time at 9:30 am.

1. They attend standup at 10 am.

2. They receive a laptop with login information.

3. Their first email provides a link to the dev onboarding wiki.

In it, you have;

1. Guidance for git standards. 2. Information git merges. 3. High-level testing guidelines and requirements. Once ready, they receive their first task, which is to fix a bug in a chatbot. The developer clones the repo and reads the code for 30 minutes. Then, they create a branch and execute some tests locally to diagnose the bug and create a fix. It takes 2 hours. They commit and push the branch, creating a pull request to the main branch with two other reviewers. In the backend, a pipeline manages a sequence of automated steps in which the pull request builds and runs the tests. Once the code passes the tests, the pipeline creates some temporal hosting infrastructure and deploys the source. When complete, the pipeline sends a message via slack/teams/hangouts to inform everyone the pull request and preview environment are ready. The new starter and peers do the review, are happy the bug is fixed, and merge the change into the main branch. The fix is ready. The scenario was a little hypothetical. So let's begin with real-world case studies about sub-optimal developer experiences. Happy developing!