How to improve the developer experience

Stop false starts in developer onboarding

Developers come into a software project motivated, but it doesn't take long for that energy to get sapped.

"[Onboarding] is where I feel most developers lose their initial spurt of motivation," said Chris Hill, senior manager of software development at T-Mobile. An inherited software project comes with immediate barriers to productivity, such as lacking or obscure documentation and the time a developer wastes waiting for access to the code repository and dev environment.

Once work begins, the developer must grasp what the code means, how it delivers value and all the tools that are part of the dev cycle.

"Every [inherited project] feels like I stepped in the middle of an IKEA build cycle, and all the parts are missing, and there are no instructions, and there's no support line, and all the screws are stripped, and I have pressure that I should come out with my first feature next week," Hill said.

At T-Mobile, Hill prioritizes developer experience, which is comparable to user experience but specific to developers' work. A positive developer experience is one in which programmers can easily access the tools or resources they need and apply their expertise without unnecessary constraints. A good DX yields positive results that trickle down to the software's user. Many times, however, a team sets out to transform the app-dev platform and either fails quickly or, worse, just adds more Technical debt. To improve the developer experience, focus on value, time and leadership.

Understand and deliver value. Hill's group aims to ease the burden of context switches, when developers move from one tool or task to another. When there's a lower cognitive load for these work changes, it's easier for developers to understand what they have to do, and why.

Cut wait times. T-Mobile calculated that if it shaved one second off each CI/CD job across the entire enterprise, the value of that time savings would be equal to one full-time IT professional; the reduction in execution time across thousands of jobs is roughly equal to how much a new hire could accomplish in a year. Make each CI/CD job five seconds faster, and the result would equal the productivity of a small team.

Empower, don't impede. Leaders should enable developers to the fullest extent they can. Empowered developers can express their creativity to solve problems and receive fulfillment from their work. No amount of tool updates will fix a toxic DX.

Hill's department was like many development groups. They dealt with 12-hour outage bridges and large amounts of unplanned work. With this focus on developer productivity, the team improved throughput 30-fold and reduced deployment challenges.

Target developer experience with changing products and tools

Intel is a company known for its hardware products, such as microprocessors and chipsets, not its software. But Intel employs roughly 15,000 developers globally and has more than 30 software products that are integrated with and validated on hardware.

Intel faces the same challenges as other companies. Its number of products grew four-fold each of the last five years. UX is changing across a variety of devices and operating systems.

"Our ecosystem has become extremely complex and dynamic," said Madhu Datla, senior engineering manager for DevOps at Intel. "Our hardware had to be validated and released faster, with the highest quality standard possible."

In the past, Intel attempted big-bang integrations: Dev teams delivered software at arbitrary times, and systems integrators would pull all the technical and instructional resources together to see if it worked. Often, it didn't.

As part of its DevOps transformation, Intel adopted incremental development on distributed software components. All software releases go through Intel's DevOps workflow. Developers incrementally add new versions of components to a single shared repository, where they are then assembled into one kit. Intel determines the target customer, such as IoT or data center platforms, then enables or optimizes configurations for that target customer.

Intel's teams use a diverse array of commercial and open source development tools for their CI/CD pipelines. Rather than try to limit teams to a single toolchain, Intel set rules for how tools in those chains should work together.

• Code should be inner sourced so all developers can debug or simply learn from it.
• Binary storage must be available.
• Build infrastructure and code capacity must be shared worldwide via hybrid cloud.
• The toolchain must be reexamined every three to five years to stay current with best practices. Intel uses an abstract build interface and reusable libraries to ensure the pipeline logic holds, even if teams switch tools.