The Voice of the Developer
Capturing perspectives from developers about the software development process.
This is the latest issue of my newsletter. Each week I cover research, opinion, or practice in the field of developer productivity and experience.
This week I read The Voice of the Developer by Ipek Ozkaya from the Carnegie Mellon Software Engineering Institute. Here, Ozkaya discusses the importance of understanding the perspectives and experiences of software developers in order to improve software development processes.
My summary of the paper
The relationship between factors such as code quality and developer productivity has been established. Prior research has also explored how various factors impact developer happiness. However, these problems — technical debt, poor requirements quality, unreliable tools or automation — often get written off as “just engineering stuff.” Developers face challenges and frustrations that are not fully understood by other stakeholders.
Here, Ozkaya proposes a solution: if organizations listen to the “voice of the developer,” they would be able to locate the areas that cause developers frustration, advocate for investments, and ultimately improve the software development process and outcomes.
Ozkaya describes the voice of the developer as “capturing whether the product enables the developer to achieve the task at hand with reasonable satisfaction and manageable stress and frustration.” The author says that companies can capture the voice of the developer through surveys and interviews, and suggests some categories of topics to ask developers about:
Architecture. “The harder it is to understand a system’s architecture, the harder it is to contribute to its evolution and sustainment. High architecture complexity also implies an increased cost of development for new features.” By asking developers about the complexity of a system’s architecture, we can identify areas that cause delays.
Code quality. “Messy code will drive messy behavior and frustration, limit understandability, and, consequently, induce stress in its developers and invoke a vicious cycle of bugs, vulnerabilities, and technical debt that is hard to get past.” Organizations can ask developers about whether code is easy to understand and work with. Quality is linked to both developer productivity and happiness, so improvements in this area will lead to improvements in engineering outcomes.
Development infrastructure. “If developers do not have access to the most current tools that make their day-to-day jobs easier, they will not only have a lack of productive output but also frustration and stress.” Developers can be asked about their satisfaction with specific tools, as well as problems that can be solved by tools (e.g., build or tests), to identify opportunities where investing in tooling would make engineering more efficient.
Incentives to report problems. “Developers often know where issues are; they discuss these in the coffee room, over lunch, and, sometimes, during reviews and retrospectives. However, when schedule and resource challenges hit, developers may or may not be incentivized to share some of the issues they see in the product.” Ozkaya adds, “Organizations should provide their developers avenues where their voices are heard.” They can also focus on creating a culture where these problems are treated as a high priority to address.
Ozkaya concludes with an argument that developers should be involved in the process of identifying and addressing issues related to the software development processes, as they are often the ones with the most direct experience and insight into the challenges they face.
This newsletter has previously shared different ways for engineering teams to communicate the reality on the ground — for example, calculating time wasted from problems like technical debt, calculating the business impact of different initiatives, or pointing to research that links factors like code quality, flaky tests, and satisfaction to developer productivity. This paper offers another approach to communicate the importance of investing in these areas: capturing and sharing developer perceptions about different parts of the software development process.
That’s it for this week! If this email was forwarded to you, subscribe here so you don’t miss any future posts:
Share your thoughts and feedback anytime by replying to this email.