4 personal and tool-based methods for creating strong feedback loops
Practical examples of how to integrate personal and tool-based feedback into your code review process.
Spiral staircase (source: Stokpic via Pixabay)
In one of my previous posts, I explained how strong feedback loops make strong software teams and how the most effective feedback loops are a mixture of daily best practices, automation, tools, and human intervention. Good quality control combines tool-based measurement with manual review and discussion.
This follow-up post offers examples of specific practices that integrate personal and tool-based feedback, which will help you bolster your code and architectural quality. These four practices might already be part of your day-to-day operations, but you need to make sure you’re getting the most out of them in terms of increasing your code and product quality.
Learn faster. Dig deeper. See farther.
1. Pull requests and code reviews
Pull requests let other team members know if code is ready to be merged and deployed without requiring them to check statuses continuously. It will also allow team members to do code reviews before deployment and provide feedback. Various research—including a survey conducted by SIG and O’Reilly of more than 1,400 developers, as well as other studies—shows that peer-led, manual code reviews are the most effective method to address code quality during the development process. This research also shows that tools usage is the second most effective method. It stands to reason, then, that a combination of interpersonal and tool-based feedback yields the highest quality code during review.
2. Static analysis tools
Objective, tool-based assessment provides immediate, actionable feedback on the quality of your code so you know what to improve and where to start. The aforementioned research shows that the most valued capabilities of code quality tools are finding security vulnerabilities, identifying violations of software design guidelines, and providing metrics on test coverage. The most effective tools for your team may vary, but static analysis tools are integral to a rigorous code review process.
3. Autonomous teams
Teams having to wait for each other and hand over phases will slow down your development process. Autonomous teams can establish their own shared goals, language, and boundaries—a “shared sense of reality,” so to speak. Your technical architecture needs to be mapped to these teams, because different teams need to work in separate code bases. This autonomy will decrease dependencies and increase your teams’ productivity.
4. Retrospective and daily scrum
Use these occasions to reflect on goals, progress, dependencies, and alignment. Doing so will help teams maintain that shared sense of reality mentioned above. Make sure product owners and users are part of this feedback loop, too.
Daily scrums are also perfect opportunities to agree on measurable definitions of “done” for each team, which will allow you to keep track of progress and maintain quality.
A shared reality
When teams have common standards, metrics, and techniques, they are more productive. Moreover, regularly validating and reflecting on this shared reality through feedback loops is crucial for product quality.
This list is obviously not exhaustive, but it helps to illustrate how tool-based and personal feedback reinforce each other and enable efficiency. With an effective, rigorous code review process in place, development teams can spend their time actually addressing any issues the review process uncovers, allowing them to focus on the right priorities and be as productive as possible.
This post is a collaboration between O’Reilly and SIG. See our statement of editorial independence.