James Turner recently interviewed Alex Martelli at the O'Reilly Open Source Convention (OSCON). Alex is well known in the Python community. He is also a tech lead at Google. The subject of the interview was Code Reviews, which you know I have an interest in. So I thought I would go over and comment on the Alex's points.The purpose of a code review is to catch errors. However a byproduct of reviews is also for developers to learn. Some things a code review can accomplish are to fix mistakes, ensure a uniform style of coding, check for good variable names, and factor our common functionality.
Obviously there are some shortcomings to the current method of conducting code reviews. Junior developers get intimidated by senior ones, especially when the old salts have big egos. In other scenarios the developers say nothing during a review. They have the attitude that they want to get out as soon as possible, so they state that everything looks fine. At the other end of the extreme are developers who nitpick every little thing they can with the code reviewed. Finally there is a lack of good tools to help code reviews.
Alex had some advice on how to improve the code review situation. He recommends that reviewers ask questions instead of criticize the developer. All people involved with code review should treat the activity as a way to learn. It helps immensely if the developers are humble and have integrity. And using software to assist the process is valuable. A tool which allows a reviewer to read the code, click points of interest, enter comments, and respond to comments is invaluable.
Alex also provided some examples of code review from the commercial community. Apaches uses an empty bug list as the signal to enter code review. Test Driven Development (TDD) seems to be taking the place of code review at many commercial development firms. However such techniques will not find some subset of problems such as race conditions and/or deadlocks. Pair programming also replaces code review in other locations. But after two developers have paired up for a while, it becomes hard to conduct independent review.
Prior to the interview, I had never heard of Alex Martelli. However I decided to listen to the video interview since he worked for Google. And I had respect for him having heard the insight he provided on code reviews. In closing he had mentioned the use of defect injection, where defects are randomly introduced into a system. The code review process is then judged by how many such defects are caught. Perhaps I shall try to introduce this technique into our own software development team. It might be a starting point to fix the movement away from code reviews on my project. I will let you know how that goes.
