DEVOPSdigest

As the debate rages on within companies of all sizes on who should "own" software quality, and at what stage(s) of the SDLC should testing be performed, an interesting finding popped up in the most recent SmartBear State of Software Quality | Code Review report. Close to 800 participants in the survey — nearly 80% of which define their roles as either developers, architects, or systems engineers — stated that code review is the number one thing a company can do to improve code quality.

In looking at a previous years' findings, code review also took the top spot in 2020, but it was in a sharp decline from its highest-ever spot in 2019. At the same time, unit testing, which has come in second place each year, was on a sharp upswing in 2020's report, nearly tying code review for the top ranking. However, in 2021, code review is trending upward again, while unit testing is headed in the opposite direction.

No matter which of the two that respondents believe is the best contributor to overall code quality, code review and unit testing enable issues to be spotted and remediated early in the development lifecycle. When performed together — it should never be an "either/or" decision—these two can prevent higher costs to repair, greater threats to scheduled release dates, or bugs slipping through to production and being found by your customers.

As to how often code review sessions are being performed, and how often they perhaps should be performed (though, there is no "one size fits all" for anything in software development), more than 70% of respondents reported that they participate in code review on a weekly basis. At the same time, respondents were asked if they're satisfied with their team's current code review processes. Forty-three percent reported being satisfied, and 11% were very satisfied.

Personally, I'd love to speak with some of the 28%, a pretty large percentage, who reported being simply "neutral" about the code review processes currently being conducted by their teams. Questions like:

Does your whole team share this feeling?

What would make your team more satisfied with more code review frequency?

Moving from ad-hoc to tool-based?

What benefits, not just to your code, but what benefits are you receiving from your code review sessions?

What are you learning?"

Speaking of the learning opportunities available within code review sessions, I was thrilled to see that 82% of respondents (54% agree/28% strongly agree) don't just learn, but learn often, and learn from the other people, not just from the evolutions of their code. Improvements to software quality will likely always be the most important benefit of code review to most developers (90% said so), but 75% rated knowledge sharing highly, 61% said it helps with mentoring new developers, and 52% recognized code review's contribution toward increased collaboration. I love all of these responses.

The invaluable learning that can take place during code review sessions is immensely important to never lose sight of. As teams make knowledge sharing an even greater priority, I think, and hope, we'll see those who "strongly agree" with being satisfied with their current code review processes take up a lot more of the pie than it does today. And to the 11% who are highly satisfied today, congratulations! Now it's time to help others feel the same way.