What Drives Adoption of Internal Developer Tools?
Keys to success for platform teams and leaders.
This is the latest issue of my newsletter. Each week I cover the latest research and perspectives on developer productivity.
This week I read Which Factors Influence Practitioners' Usage of Build Automation Tools? by Akond Rahman, Asif Partho, David Meder, and Laurie Williams. This paper studies the factors affecting adoption of internal developer tools (specifically build automation tools, for this study). These findings provide important considerations for platform teams and engineering leaders who are looking to drive adoption of new development tools.
My summary the paper
The paper opens with examples of well-established organizations suffering from problems caused by not using automated build tools. According to a more recent report, despite the evidence for using build automation tools, software professionals are hesitant to adopt them. The motivation for this study was to identify the reasons why.
The researchers conducted a survey with software professionals working at various companies as well as some who contribute to open source software. The survey focused on four specific types of tools: build tools, continuous integration (CI) tools, infrastructure as code tools, and version control tools. The survey was designed to only ask developers about tools they were familiar with. Developers were asked about their usage of each tool as well as the adoption factors that influenced their usage. The adoption factors respondents could choose from were based on prior research.
Here’s what the researchers found.
The factors that influence usage of build automation tools
The researchers analyzed the results in two phases: first, they applied linear regression to identify the adoption factors that can influence usage for each tool. Then, an additional analysis was performed to prioritize the adoption factors to understand which are most influential for each build automation tool.
For build tools (tools compile software changes into executable binaries), the highest priority adoption factor is whether the tool is highly configurable.
For continuous integration tools (tools integrate software changes into the shared mainline of the software), the highest priority adoption factor is whether the tool is compatible with the technologies developers use.
For infrastructure as code tools (tools that manage configuration options of the software as well as configure the deployment environment), the highest priority adoption factor is how visible the usage of the tool is within the organization.
For version control tools (tools that manage all the changes of artifacts related to the software of interest), the highest priority adoption factor is whether the tool fits well with the way developers work.
Overall, this analysis indicates that compatibility and observability-related factors have relatively more influence on usage. The researchers define compatibility as accounting for the level of how a new technology is consistent with existing experiences and practices. Observability indicates how the results of a new tools' usage are visible to other tool users.
The papers concludes with some suggested actions to improve the compatibility and observability of tools and, in turn, improve the tools’ adoption:
The findings indicate that developers do not want to change their usual style of work, and might prefer tools that are easy to integrate with their usual style of work. Select or design tools that fit well with the usual work style of team members and that can be easily customized to their needs.
The findings imply that developers are more likely to adopt tools that are used by their peers or by their community. Consider developer-led blog posts or demonstrations of build automation tools at company events and public events.
Final thoughts
In my recent conversations with Manuel Pais (Team Topologies) and Max Kanat-Alexander (LinkedIn), both of them brought up how platform teams often don’t have a great understanding of their customers (i.e., developers). As a result, they may focus on the wrong problems or build solutions in a way that fails to get adoption.
This paper further supports the need for platform teams to understand developers’ existing workflows before designing solutions. While many tooling owners look to education-related strategies to improve adoption, this study suggests that they should consider iterating on tools so they fit how developers work, as well as make tools more visible amongst developers’ peers.
That’s it for this week! Share your thoughts and feedback anytime by replying to this email.
If this email was forwarded to you, subscribe here so you don’t miss any future posts:
-Abi