Last week I discussed the virtue of designing a complicated system through team effort. This week I would to comment on the value of reviewing written code as a team.

Peer review has long been a highlighted event in software development as a method to increase quality and catch bugs as early as possible in the software design cycle. Often peer review is conducted by one other colleague and may be performed without direct interaction with the code author. The peer review may generate questions and dialogue between the author and reviewer, however this tends to be minimal unless there are major coding problems.

I would like to propose that instead of a peer reviewing the code, the code author be charged with presenting the code that was authored. This does not need to be a full power point presentation, but should involve bringing the entire team together and looking at every line of code. I believe that the following benefits will be achieved with this code presentation.

Increased adherence to coding standards:
Often developers believe that they work in a bubble, where the only thing that matters is that the code they produce works. This is after all the primary objective, so less importance is placed on readability, proper structure, commenting, and use of naming conventions. If they are aware that once they have completed their assignment they are going to be asked to present their code to a room of their peers, chances are they will pay a little more attention to the little things that make code maintenance a lot less frustrating.

Increased quality:
During the informal presentation of the code the developer will have the opportunity to explain all decisions that were made, and justify them against questions from the floor. These question and answer sessions may result in a tighter design, or may highlight logic faults or bugs in the software. Often someone in the group will think of a scenario that was not considered by the code author. This scenario can be discussed as a group in terms of the written code, and if necessary a proposed solution can be presented (think Team Design).

Team Skill Level Increase:
While attending the code presentation each member of the team is able to learn how others solve design challenges. These solutions may be extremely helpful to members of the team as they work on their own assignments. Possible private sub-routines written for one program may be used wholly or in part by a different developer. With this increased exposure, code authoring techniques and existing code can be leveraged to increase the skill level of the entire development team.

Presentation Skills:
Public speaking is not usually at the top of desired requirements in a job description. This is not uncommon in any industry, however I think that software developers are even less of a "people person" then the average field. Most developers are extremely proud of the code that they write. Giving them the ability to present this code should increase their comfort level within the group and provide each member of the team the self-confidence to present their ideas in other areas.

Public acknowledgement:
A proper run Team Code Review should never end without any required modifications to the code. This should be the goal of every presenter however the reality is that perfect code is rarely achieved with the first draft. That being said, well-written code is easy to distinguish from code that should be started over again. A Team Code Review is an excellent opportunity to acknowledgement the presenter for a job well done when it is deserved.