Code review for non-experts

Code Review is an important software quality assurance technique where one programmer’s code is read through by another fellow-programmer to find defects in the code. Currently, this task is performed by programmers who are experienced with the code and the domain of the software. Usually, these are the expensive expert programmers who could be utilizing their time in more important programming tasks. As a result, code review is considered by programmers to be an expensive process. As a solution to this problem, I am looking at the possibility of getting less-expensive non-experts (novice programmers and other professionals who are not programmers) to contribute to code review. 

To achieve this objective, I started by conducting a systematic mapping study and an online survey to understand the current state of code review in practice. Next, I classified a sample of code review defects extracted from the CROP dataset (https://crop-repo.github.io/#structure) to identify types of defects that are usually detected during code review. Based on this classification, I then conducted a preliminary survey to understand how developers and non-developers make decisions essentially related to code review. The types of defects I selected for this preliminary study were related to identifier name quality, class cohesion, and software-generated messages. This study showed that non-developers can make decisions similar to developers in some cases even without any prior training. I’m currently conducting an experiment where the non-developers are non-extensively trained prior to performing code review tasks to see if there is any progress in their performance due to training. I am also trying to understand their thinking process by getting them to think aloud while they are performing the code review tasks.

 I start my usual day by looking at the to-do list I have on my whiteboard. Each of these tasks is usually given a priority number on which I prioritize the work to be done. I mostly work on my computer, designing and planning surveys and experiments, writing papers, and analyzing data collected from previous studies. Sometimes I schedule 1-3 interviews per day with the participants of the experiment I am conducting currently where I sit and talk with them. I find these interview sessions very interesting and fun. Also, some days I meet my supervisor for research discussions or participate in group discussions conducted by research groups in the university. During the lunch break, I have a hearty meal and socialize with the fellow students. At the end of the day, I update my to-do list for the next day.  

 What I enjoy the most about my research is that it is my own research idea that I’m working on. I experienced the difficulty of managing code review tasks with other programming tasks myself and wanted to find a solution to the problem. I love the fact that while completing my PhD, I, as a software engineer, am also able to do something that matters, something that will be directly beneficial to my fellow software engineers.

 Something that surprised me in the course of my research is how much I realized I did not know. Doing my PhD helped me acquire a lot of new knowledge, research skills, and life-skills. It taught me how to live like an academic, how to research effectively, how to handle pressure, how to stay calm in difficult situations, and how to get back the control in uncontrollable situations. My supervisors were beyond helpful and are the reason if I am a successful researcher today.

 The main challenges I faced were related to the uncertainty of my research project. Since I came up with my own research idea, I was dubious at first of the scope of the research, the direction the research will take, and whether the outcome will be useful. Talking to my highly experienced and supportive supervisors always helps me to overcome these doubts and feel confident about the research that I am working on. So, even today, I never miss our weekly meeting.

The question that I am trying to find answers to now is “Can programming non-experts contribute to code review?”.

 I hope my research will cause improved financial performance in software engineering organizations by allowing them to utilize their human resources more effectively in the code review process. I also hope my research will cause improved productivity in software engineers by releasing them from the burden imposed by code review tasks that could have been performed by less-expensive resources.

 I collaborate with Dr.Kelly Blincoe and Peter Devine, both from Electrical, Computer, and Software Engineering on a project funded by Google. The project is on “Destructive Criticism in Software Code Review and its Impact on Diversity and Inclusion”. As a researcher who is interested in human aspects of computing, and specifically code review, this project helps to widen my knowledge on code review research further. Also, it is enlightening to work with a great team rather than working alone.

 I am also working as a Graduate Teaching Assistant (GTA) at the school of Computer Science. Collaborating with university staff such as Associate Professor Ewan Tempero, Yi-Chien Vita Tsai, Tyne Crow, Dr.Andrew Meads to help students has been an amazing experience. Being a GTA made me realize how much I enjoy talking to and working with students. It is a very fulfilling job.

 The one piece of advice I would give my younger, less experienced research self is "Be brave and persistent and everything will work in your favor".