Agile 101 - Code Reviews (Part 1 of 2)

Programming is typically a solitary affair. Even though there may be dozens of people working on the code, each person typically works by himself to perform the initial construction and unit testing. In fact, most programmers prefer it that way. They enjoy the challenge of developing code to perform a business function and they like the feeling of accomplishment that comes with getting the code completed and successfully unit tested.

A good technique to ensure initial code quality is to have a code review. This allows another person or a small group to walk through the code and provide additional feedback about the structure and quality of the code. Since the program was probably written and unit-tested independently, this is the first opportunity for others to see the work. (Pair programming note. Of course, this code review step would not be needed if your team is utilizing the pair programming technique. In pair programming the code is reviewed and critiqued by a second person while it is being developed. This is the topic for a future column.)

Is it Agile?

Let me state for the record that code reviews are not universally viewed as an Agile technique. Many teams feel that Agile development rises to a level where the reviews are not needed. There is also a belief that any problem code can be identified and fixed in a future iteration through refactoring. However, there are still benefits that make the technique relevant.

• Find bugs faster. In many cases, the original programmer cannot catch all the bugs because he is making assumptions about how events will occur and how the code will respond. A second person without those same assumptions may turn up potential logic errors that the original programmer did not see. This is one of the benefits of pair programming, and the logic for the second set of eyes still makes sense for teams not doing pair programming.
• Enforce construct standards. If your organization or your team has standards and guidelines to follow, the code review can validate that these standards were followed. Yes it is true that code that does not follow standards can be refactored later, but that seems like needless work. The code review catches the problem while the code is still with the original owner.
• Ensure sufficient documentation. The person that wrote the program knows what the code does. It is not that obvious to anyone else. The review can ensure that there are sufficient comments to make sure others can understand the logic flow as well. Agile projects do not rely on heavy external code documentation. The code is the documentation. The code reviews make sure the code and comments are actually self-explanatory.
• Collective ownership. The code review can help others become more familiar with programs. This fits the Agile philosophy of collective code ownership. Code reviews can help bring collective team knowledge to the code.

Of course, there are costs as well. These fall into two areas. First, it takes time and effort to hold code reviews. This includes preparation time as well as everyone's time that attends the meeting (see below for alternatives). Second, there can be hurt feelings. When the team is comfortable with code reviews, you become very open to constructive criticism and challenges. However, when you first start the reviews, the owner of the code may take offense to other people challenging his work.

Next week - Processes and techniques for Agile code reviews.

........................................................

Project Management Suite. Get pre-built issues management process and much, much more with the TenStep Project Management Suite. Companies and individuals.Click here for more information.