Code Review 6) Implementation strategy

Welcome to BSP Software’s ‘Code Review’ series

Part 1) Author and Reviewer Preparation
Part 2) Readibility
Part 3) Structure
Part 4) Algorithmic soundness
Part 5) Bus found, now what?

Peter Gabris, MD of BSP Software Inc

In this section we focus on
Part 6) Implementation strategy

Successful implementation of peer code reviews in an organization has to overcome natural resistance. There are many reasons of the resistance: natural resistance to innovation, code ownership, people who are really overloaded with work and many others. And there are some professionally insecure programmers as well. Let’s list a few typical objections:

1. I (we) do not have time to do that. The production is waiting for the code. The deadline was yesterday. I have no tome to prepare the code for the review.
2. It’s not going to improve anything.
3. The process is too formal (or disorganized).
4. Code reviews are too new (or too old).
5. This is too costly.
6. The code (or the change to the existing code) is too big for review (or the change in the existing
   application is too small to require the review).
7. We do not have the right tool for code reviews.
8. Our code (language, platform, framework, methodology) is so special nobody can understand (or anybody can see it is correct even without a review).
9. I could not clean (or even fix) all the legacy code I am changing.
10. This is the best code I found on google (or in a textbook).

Taking care of the Programmer’s Ego

1. The programmer can select the reviewer. The team leader approves it and informs the project
   manager. Only in extreme cases can the team leader intervene in the reviewer selection. However, programmers will be asked not to stay with the same reviewer permanently.
2. Reviewer communicates his comments and concerns to the code author only. It is the code author’s choice to share the communication with anybody else.
3. Reviewers know their code will be up for the review one day as well.
4. Programmer is not responsible for the legacy code he-she is changing. However, the code should be improved by the change. That might require cleaning the immediate vicinity of the change and fitting the change technology and style to the existing code.
5. The message from the reviewer to the project manager says only that the code was reviewed.
6. Reviewers do not report their time spent on the code review into the project plan of the reviewed code. The time is reported to the general administrative and QA time pool.
   

    Time concerns and the size of the code

   We ask programmers not wait with the code review request too long. One month of the coding work should be the upper limit where the project manager should inquire if the work with the code reviewer started. Each code part (as defined in the project plan) can be reviewed right when it is finished. We do not need to stretch the project plan by injecting code review steps. Code reviews are part of the coding process itself and occur during the process, not after.

Code Review continues in Part 7) Tools of the Trade

Feel free to leave any questions or comments below