Where I work we are using code reviews, so each developer as peer is reviewing the code of another developer, using a review cycle where each review session is made to any different member of the team. All reviews are done in the team as peers, making the team responsible about the code that is sent to the QA stage. This help us to detect errors that cannot be seen by the programmer that owns a task, because is hard to see our own programming mistakes, and the team knowledge is balanced incrementally on each review. We are using Atlassian FishEye for code reviews, and we comment each commit when it is required, with internet links to well known bugs, documentation and papers, documenting each comment. Each team member knows about their peer programming tasks and how those tasks will affect his own tasks, and due to the system complexity we must avoid as much programming errors as we can — usually we do not send code with bugs to QA and we are constantly passing all tests.
The review process is done at the end of the workday, and sometimes some tasks to be dragged back, but asking for enhancements. Also, this allows project leaders and architects to monitor the skills of each programmer, so they can decide who will lead another project if a new team is created. That’s pretty nice, because someone with both good communication skills and programming skills can participate on higher levels of the development process once his skills are confirmed. And the increasing team balance grows quickly, because everyone can review all comments and commits, and see how each peer has solved a problem, and participate on the commit comments. Another good open source example is how github uses the commit comments. You can find very interesting comments on each project and this allows a direct participation of other programmers in the development process.
Since I usually do not work on-site, I can work using pair programming, but strictly on certain exceptions. I must recognize to work alone and then do some code review, because I work more concentrated on my office. I think that it is a great advantage. Now I have my own office, I drink coffee made with natural coffee beans, and can listen that music that I want. I feel very comfortable on my current workspace.
Another good aspect of doing code reviews, is the fact that ego driven developers — usually mere idiots — are running very far away from this team, because we they do not tolerate any kind of criticism. Two developers have left the team because they were not able to handle the code review. Higher egos cannot participate of our current development process, because we want everything to be done very well, and almost perfect. We have a very good team. So, code reviews are helping with a real contribution in the team balance and confidence, and I think that every team should be able to work using code reviews.
Entries 