RFC: Evaluating Value vs Pain for Code Reviews

Hi Esteemed members of Dev.to

I am working on creating a questionnaire to evaluate the performance of Code Reviews. As you may have already seen on this year’s State of DevOps Report, code reviews have a huge impact on organization performance. It certainly makes a great argument for pair programming.

In order to surface the miss-givings of code review culture and process of a team, data collection is a necessary step. Hence, I’ve taken the first step to designing a questionnaire that would help provide data to answer the value vs pain/loss of pull requests. I would like to get some comments on my questionnaire design.

Here are the questions I am trying to answer:

1. How much time is lost in waiting for code reviews?
2. How much of a developer’s time is spent reviewing code?
3. Are they accomplishing their target or preventing bugs and design degradation?

Please leave me your comments on what you think about the questions. I would like to know

1. If the questions were clear and unambiguous
2. If the options were sufficient and fair
3. If you think I should add more questions
4. Or maybe you think there is a better way of accomplishing my goal

The Questions

Here are the list of questions I’ve developed so far.

• Are you a default/required reviewer?
  • yes/no
• During the past month, how much time did you typically dedicate to reviewing code in a given day?
• During the past month, how many code reviews did you perform per day?
• During the past month, how many change requests took you longer than 15 minutes to review in a given day?
• During the past month, how long in average did you have to wait for your code to be reviewed?
• When you review code, how much do you agree with the following statements? More often than not, I
  • can identify the changes made
  • have a clear understanding of the changes made
  • have a clear understanding of the context (reason) for the changes made
  • have sufficient time to conduct a comprehensive and high-quality review
  • feel confident to approve after a review
• What is the average size of changes you review?
• Do you feel responsible when code you approved introduces issues in the production environment?
• How valuable do you perceive code reviews to be (Very Valuable, Somewhat Valuable, No Value)
  • maintaining code quality
  • knowledge sharing
  • preventing functional/logical issues
  • preventing performance issues
  • preventing security issues
  • maintaining system design/architecture
  • fostering team collaboration
• What do you primarily focus on when reviewing code change? (Select 3)
  • maintaining code quality
  • knowledge sharing
  • preventing functional/logical issues
  • preventing performance issues
  • preventing security issues
  • maintaining system design/architecture
  • fostering team collaboration
• How often do you give or receive comments regarding: (Very frequently, Here and There, Rarely)
  • maintaining code quality and formatting
  • functional/logical issues
  • performance issues
  • security issues
  • system design/architecture
• When you create a change request, do you trust reviews to identify bugs (functional, logical, performance, or security issues)?
• Of the functional, logical, performance, or security issues discovered during QA, how many of them could have been identified during a code review?
• What are the frequent reasons for buggy code getting past code review?

I hope to hear from you; Adios