The developer experience (dX) has similar outcomes to user experience (UX). Great developer experiences are fast, intuitive, reliable and straightforward. A new developer should be able to join your team and during the onboarding process, be productive in less than an hour. While this isn’t mandatory, we don’t think the dX should include any tools other than the source code manager and the integrated development environment. Like git and a text editor).
Why optimise the dX
The work of developing software happens daily, and as part of your DevOps transformation, you collect numerous metrics. You may be able to quantify improvements to the dX before you see benefits to the project or transformation programme. Improvements to the dX can be leading indicators of project success. We also find that a focus on the developer experience is an excellent way to boost productivity and achieve high-value organisational outcomes. For example, Projects run smoother, and developers are happier and more empowered.
Imagine this scenario. A developer joins your organisation. Their first day is exciting; they arrive on time at 9:30 am. They attend standup at 10 am. They receive a laptop with login information. Their first email provides a link to the dev onboarding wiki.
In it you have;
- guidance for basic git configurations
- information around git merge strategies
- contributing to software projects
- testing guidelines and requirements
Once ready they receive their first task, it is to fix a bug in a chatbot.
The developer clones the repo and reads the code for 30 minutes. They create a branch execute it locally to diagnose the bug and create a fix. It takes 2 hours. They commit and push the branch and then they create a pull request to the master branch with two other reviewers. In the backend, a pipeline manages a sequence of automated steps which the pull request build and tests the code. 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 and are happy the bug is fixed and merge the change into the trunk branch. The fix is ready.
In the scenario, I mentioned a pipeline, test automation, slack messages, infrastructure provisioning and deployment automation. These are some of the valuable components used to create good developer experiences; however, in almost all cases, the devil is in the detail. What I mean by this is;
The developer should have to be aware of any of this. The developer should not context switch. The test automation infrastructure runs on all branches. We use chat, so the developer doesn’t have to context switch. We don’t introduce any new tools to their ecosystem. Speed is crucial we aim for < 4minute pipeline runs.
Ok, the scenario was a little hypothetical. Let’s begin with real-world case studies about sub-optimal developer experiences.
Example: Dev Team in mainland China
Working with a multi-national organisation we had the opportunity to serve a team based in mainland China. I began working with this team by trying to retro-fit the developers experience we had created for similar teams from the multi-national based in Europe. Mainland China feels far away because of the great firewall, and quite a few dependencies cause issues for pipelines, build and test strategies. Once our pipelines and build process were in use we received many complaints that the developer experience we had created was slow. Worse still the pipelines were designed to build on a commit-hook which resulted in single commits taking 15-minutes to complete and creating massive backlogs. In this case, the developer experience resulted in wasted time, frustration and longer-term would have resulted in delayed releases and a full-on mutiny.
Example: Mobile Development in the UK
Working with a different multi-national, we were asked to help improve how they build mobile apps (i.e. IOS apps). At the time, we noted that builds were taking over 15 minutes to complete. Unless compiling locally, developers were only able to integrate on specific branches, which led to a variety of problems when finalising features and added additional time to the process of releasing. In this case, we identified frustrations around the time it took to build, test and integrate. Developers felt they had wasted a lot of time preparing releases and our mission was to help them gain a few more hours of productivity.
In the above two examples, we are dealing with two distinct software platforms. The China development team are using various backend and frontend development stacks with docker. The mobile development team are just using IOS. In China, our fundamental improvement was to improve the speed of the pipeline. To do this, we needed to move most of the dependencies to locations inside the great firewall. We also set up a devops cluster in mainland china. This fix reduced the build and deployment times to about 4 minutes, and our developers were much happier, and they were notably more productive.
To fix the mobile development teams process, we moved them away from a dedicated mobile CICD solution to our platform. With the Fastlane project and with our build cloud, we were able to set up a multi-branch pipeline so that even the smallest features could be tested. With Fastlane and our Build cloud, we reduced the build time to less than 5 minutes on average. The development team could build twice as much in the time it took them previously to build once.
The developer experience in the above two examples is straightforward, and we want our customers to do more of this. That is why we are here. We’ll take care of the infrastructure so you can improve the developers experience within your organisation.
I believe DevOps Engineers should be guardians for the developer’s experience. To help, we are launching some source code which will help you construct innovative Jenkins pipelines.
What is your developer experience within your organisation?