This isn’t groundbreaking news for any of us, but the business world has changed drastically over the past few years. Even though it might be a new situation for most industries to be facilitating remote work and trying to create excellent WFH environments for their employees, it turns out that this isn’t necessarily a new challenge for software development teams.
It’s more important than ever for teams to consider daily dev experience.
“New ways of working such as globally distributed development or the integration of self-motivated external developers into software ecosystems will require a better and more comprehensive understanding of developers’ feelings, perceptions, motivations, and identification with their tasks in their respective project environments.” - Fagerholm, Fabian & Münch, Jürgen. (2012). Developer Experience: Concept and Definition.
The two driving factors of dev experience are globally-distributed teams and self-motivated developers. The entire world is shifting towards a distributed workforce. And The Great Resignation has proven that developers are very much self-motivated, and ready to jump ship if their roles aren't a good fit for them.
The best way for businesses to respond to these shifts is by focusing on dev experience: gaining a better, holistic understanding of developer perceptions, motivation, and feelings around their journey and the tasks in their project environments, then fixing any issues that cause frustration or slowdowns. Those are the big ideas behind developer experience.
Dev experience encompasses all of the interactions and resulting feelings that affect developers daily. It’s all about thinking through the people, processes, and technologies that a developer crosses paths with on the daily, and what those interactions feel like to their everyday productivity and job satisfaction.
Dev experience is comparable to the practices of user experience: simply making the lives of users easier by streamlining processes, creating better communication between people, and implementing technologies that mesh well together and provide value. Even though dev experience is about understanding what your developers go through each day, it’s also about proactively instituting changes that will make their jobs much better.
Developer experience can seem like a daunting concept though. Where exactly do you begin in working on something that’s pretty vague and subjective? Back in 2012, Fabian Fagerholm and Jüergen Müench wrote a research paper about dev experience, categorizing three anchors that still apply today.
The cognition component of dev experience focuses on understanding what developers think of the end-to-end development infrastructure. This covers everything from the skills they’re expected to have, the procedures and techniques they’re expected to execute, and the processes and platforms they're expected to use.
The way that developers feel about their work influences whether they have a positive or negative dev experience. This covers factors like respect amongst team members, the feeling of social belonging, and attachment to the team. Developer experience directly relates to the feeling of work because bad infrastructure directly creates negative emotions such as frustration and being overwhelmed.
It’s important that developers see the value in the part they play within the development structure. Conation relates to the plans and goals of the organization, alignment and commitment of the developers with said goals, and their individual motivations and intentions when working on these long-term roadmaps.
How do these all connect together?
“[S]oftware development is an intellectual activity, which rests on the capabilities of the mind, requiring both thought and motivation to carry out. In psychology, the concept of mind is commonly divided into cognition (attention, memory, producing and understanding language, problem-solving, decision-making), affect (feeling, emotion), and conation (impulse, desire, volition, striving)...Since the end goal in the developer perspective is to create software, it is especially important to consider how thought and feeling is turned into intentional action, and how group work should be systematically organized to support this.” - Fagerholm, Fabian & Münch, Jürgen. (2012). Developer Experience: Concept and Definition.
Poorly implemented processes and tools harm dev experience by causing frustration, redundancy, and mistrust.
The CI/CD pipeline is a great example of a process-technology combo that can greatly improve the developer experience. It falls under the umbrella of DevOps, which seeks to create a culture and processes of shared responsibility across previously-siloed parts of the development cycle.
CI, which stands for Continuous Integration, focuses on making the first half of the development process easier, by adding automated testing and build compilation, along with implementing a source code repository to ensure that developers create compatible and non-repetitive code snippets. CD, which can either stand for Continuous Delivery or Continuous Deployment, focuses on the second half of the development process. Continuous Delivery automatically brings builds out of the repository into the test environment, while Continuous Deployment goes a step further than that by running the tests automatically and deploying the builds into production without human intervention.
As teams implement a CI/CD pipeline, they install helpful automation tools, and document ways to pass builds downstream as smoothly as possible. Even though these changes are related to tools and processes, they end up impacting dev experience. With a set process and great automations, developers can thrive in an organized environment with a minimal amount of repetitive tasks.
Dev experience comes down to thinking through the three anchors. People, processes, and technologies should give developers more autonomy and nurture less stress.
How do we connect these concepts to the current state of software development? And where is the industry at in further improving developer experience?
Well first off, it’s important to realize that dev experience relies heavily on effective infrastructure and processes. We know that today’s methodologies like DevOps and the CI/CD pipeline have helped make improvements to a point. But, dev experience is still a work in progress for many and there are things that still need to be focused on to truly improve it.
Automated testing has helped dev experience to a point, but with that automation has come a tsunami of data that is being underutilized to fix the bloated test cycles developers are still battling.
Launchable improves dev experience with data-driven pipelines through faster, smarter testing.
Developers struggle waiting on huge test suites to run, every time they commit an artifact. None of us enjoy waiting, so it takes a toll on dev experiences over time. Predictive Test Selection uses machine learning to identify and run tests with the highest probability of failing based on code and test metadata to speed up the dev feedback loop, and improving dev experience.
Developers also struggle with understanding the health of their testing. This can lead to mistrust in the outcomes of testing and risks bugs being found later in development cycles. With Test Suite Insights teams can track how their test suites are preforming overtime. Insights on flaky tests, test session duration, test session frequency and test session failure ration arms developers with health metrics for test suites to better mitigate issues and keep testing running smooth and fast.
Start using your test suite data build a smarter data-driven pipeline for better developer experience with Launchable.