How better developer experience increases productivity
According to State of DevOps 2021, in 78 percent of organisations, DevOps implementation is stalled at a medium level. This percentage has remained almost the same for 4 years.
The vast majority of companies are stuck in mid-level DevOps development. The study divided the mid-level into three categories to explore the phenomenon in more detail.
Unsurprisingly, companies that are already well advanced in DevOps implementation have also automated the most processes. These companies also have the most top-down support for the bottom-up change (→ Top-down and bottom-up design):
Less than 2 percent of employees at highly developed companies report resistance to DevOps at the executive level, and the figure is also only 3 percent at medium-developed companies. However, only 30 percent report that DevOps is actively promoted, compared to 60 percent of highly developed companies.
A definition of DevOps suggests the reasons why many companies are stuck in implementation:
DevOps is the philosophy of unifying development and operations at the levels of culture, practice and tools to achieve faster and more frequent deployment of changes to production.
– Rob England: Define DevOps: What is DevOps?, 2014
A key aspect of DevOps culture is shared ownership of the system. It is easy for a development team to lose interest in operations and maintenance when it is handed over to another team to run. However, when the development team shares responsibility for the operation of a system throughout its lifecycle, it can better understand the problems faced by the operations team and also find ways to simplify deployment and maintenance, for example by automating deployments (→ Release, → Deploy) and improving monitoring (→ Metrics, → Incident Management, → Status page, ). Conversely, when the operations team shares responsibility for a system, they work more closely with the development team, which then has a better understanding of operational requirements.
DevOps changes
Organisational changes are needed to support a culture of shared responsibility. Development and operations shouldn’t be silos. Those responsible for operations should be involved in the development team at an early stage. Collaboration between development and operations helps with cooperation. Handoffs and releases, on the other hand, discourage, hinder shared responsibility, and encourage finger-pointing.
To work together effectively, the development and operations teams must be able to make decisions and changes. This requires trust in these autonomous teams, because only then will their approach to risk change and an environment be created that is free from fear of failure.
Feedback is essential to foster collaboration between the development team and operations staff and to continuously improve the system itself. The type of feedback can vary greatly in duration and frequency:
- Reviewing one’s own code changes should be very frequent and therefore only take a few seconds
- However, checking whether a component can be integrated with all others can take several hours and will therefore be done much less frequently.
- Checking non-functional requirements such as timing, resource consumption, maintainability etc. can also take a whole day.
- The team’s response to a technical question should not take hours or even weeks.
- The time until new team members become productive can take weeks or even months.
- Until a new service can become productive should be possible within a few days.
- However, finding errors in productive systems is often only successful after one or more days.
- A first confirmation by the target group that a change in production is accepted should be possible after a few weeks.
It should be self-explanatory that feedback loops are carried out more often when they are shorter. Early and frequent validation will also reduce later analysis and rework. Feedback loops that are easy to interpret also reduce effort significantly.
Etsy not only records whether the availability and error rate of components meet its own requirements, but also to what extent a functional change is accepted by the target group: if a change turns out to be worthless, it is removed again, thus reducing technical debt.
Developer Experience
Developer Experience (DX), which applies concepts from UX optimisation to experiences in development teams, can be a good addition here to better capture the cultural level from the development team’s perspective. In Developer Experience: Concept and Definition Fabian Fagerholm and Jürgen Münch distinguish the following three aspects:
| Aspect | Description | Topics |
|---|---|---|
| cognition | How do developers perceive the development infrastructure? |
|
| affect | How do developers feel about their work? |
|
| conation | How do developers see the value of their contribution? |
|
This is what the day might look like for members of the development team in a less effective environment:
- The day starts with a series of problems in production.
- Since there are no aggregated evaluations, the error is searched for in various log files and monitoring services.
- Finally, the problem is suspected to be swapping out memory to a swap file and the operations team is asked for more memory.
- Now it’s finally time to see if there was any feedback from the QA team on the newly implemented function.
- Then it’s already the first of several status meetings.
- Finally, development could begin, if only access to the necessary API had already been provided. Instead, phone calls are now being made to the team that provides access to the API so that we can’t start work for several days.
We could list many more blockages; in the end, the members of the development team end their working day frustrated and demotivated. Everything takes longer than it should and the day consists of never-ending obstacles and bureaucracy. Not only do development team members feel ineffective and unproductive. When they eventually accept this way of working, learned helplessness spreads among them.
In such an environment, companies usually try to measure productivity and identify the lowest performing team members by measuring the number of code changes and tickets successfully processed. In such companies, in my experience, the best professionals will leave; there is no reason for them to remain in an ineffective environment when innovative digital companies are looking for strong technical talents.
The working day in a highly effective work environment, on the other hand, might look like this:
- The day starts by looking at the team’s project management tool, e.g. a so-called Kanban board, then there is a short standup meeting after each team member is clear on what they will be working on today.
- The team member notes that the development environment has automatically received up-to-date libraries, which have also already been transferred to production as all CI/CD pipelines were green.
- Next, the changes are applied to their own development environment and the first incremental code changes are started, which can be quickly validated through unit testing.
- The next feature requires access to the API of a service for which another team is responsible. Access can be requested via a central service portal, and questions that arise are quickly answered in a chat room.
- Now the new feature can be worked on intensively for several hours without interruption.
- After the feature has been implemented and all component tests have been passed, automated tests check whether the component continues to integrate with all other components.
- Once all Continuous Integration pipelines are green, the changes are gradually released to the intended target groups in production while monitoring operational metrics.
Each member of such a development team can make incremental progress in a day and end the workday satisfied with what has been achieved. In such a work environment, work objectives can be achieved easily and efficiently and there is little friction. Team members spend most of their time creating something valuable. Being productive motivates development team members. Without friction, hey have time to think creatively and apply themselves. This is where companies focus on providing an effective technical environment.
Get in touch
We will be happy to answer your questions and create a customised offer for the DevOps transformation.
I also like to call you back!