RFC: Evaluating Value vs Pain for Code Reviews
Tags: codereview, data, devops
Published: 2023-11-08 13:56:54

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](https://cloud.google.com/blog/products/devops-sre/announcing-the-2023-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