tree bending over a path

Is reviewing code a risk ?

Some years ago, I was part of a small team in a big company. This company had locations all over the world. This means that we had to collaborate with other teams in other countries. One day, I discovered a new page on the wiki. This page was written by a developer of another team member that he was offended by a code review.

He put a link to the code review. The review comment was only 3 letters. WTF. The person who wrote the code was not very amused by this comment and felt offended. The developers on our team did not see the problem. It was just for mentioning that it was a trivial problem that everybody should know.

But was it a trivial problem? Maybe it was, but it is also possible that not everybody with other backgrounds knows what the problem was. In that case it was completely normal that the code was written that way.

Purpose of a review

Before continuing of my own opinion, let’s have a look at what the purpose of a code review can be, because there is no one-answer-to-rule-them-all. A couple reasons are:

  • Finding defects or opportunities for improvement. Code and data can be examined to find weaknesses.
  • Education of other (new) developers. Ensure that everyone sees the modification associated with a defect fix or enhancement so that they can understand the rest of the software.

Teams moral

When a code review is introduced, some people see it as a thing that will ruin the teams culture. They say that some people will be jerks about code review and use the opportunity to terrorize others.

The goal of code review is to make the software as bug-free as possible, and to teach and learn in the process. When the right attitudes are set up front, most teams unite around the concept of becoming a better team, learning from others to become better developers, and producing better products. It gives developers a framework for communication, which is a very good thing.

Of course, it is possible that team members use code review as an opportunity to try to establish superiority over others. 

This attitude is not very productive. If there is a culture open communication, you also need a culture of respect. The tone of the communication contributes to more positive attitudes. Everybody make mistakes. Mistakes should be seen as opportunities to learn.

If you set the stage right, code review doesn’t ruin your team culture, then it improves the culture!

Be careful of your tone

That leads me to a lesson that is mentioned in Cem Kaner’s book Lessons learned in Software Testing. It is about a bug report, but it can be applied to code reviews too.

Lesson number 86 is stating:

No benefit is gained by adopting a blaming or patronizing tone in your bug report. It never pays to call the programmer unprofessional, closed-minded or a fool. It might feel good in the moment, but you lose credibility invite micromanagement of your work and will be less likely to get many of your bugs fixed. Watch your formatting too. For example, reports written in ALL CAPS read as though you were screaming. If you’re not sure how the report will be read, have someone else read it and LISTEN carefully to their comments.

No benefit is gained by adopting a blaming or patronizing tone in your bug report. It never pays to call the programmer unprofessional, closed-minded or a fool. It might feel good in the moment, but you lose credibility invite micromanagement of your work and will be less likely to get many of your bugs fixed. Watch your formatting too. For example, reports written in ALL CAPS read as though you were screaming. If you’re not sure how the report will be read, have someone else read it and LISTEN carefully to their comments.

This is the same for code reviews, be polite. I want to say more, say also something good about the code. Even if you find a lot of problems in someone’s code, there is always some nice and very good things too. Make comments on that good part too. Positive comments remind the coder that there is still a lot to learn, but that he still adds value to the system.

WTF

That leads me to my point. The WTF word can be offensive that’s for sure and it is not helping the moral of the team. Be respectful and patient, remember that not every team member has the same knowledge or experience as you. At other domains, that same team member has more experience as you. Would you be treated that you where a stupid person on that domain?

  • Remember, everybody make mistakes, even you.
  • Ask a question instead of making a three or four letter word. Ask the author to explain the reasoning behind something. This will acknowledge that you respect him or her.
  • But be aware, do not ask accusatory questions. It is better to ask What did you have in mind when … than Why didn’t you … The first question opens a door for dialog and learning.

This are a few tips that I can give on code reviews and bug reporting.

Remember that all team members are on the same train. If the moral on the team is getting down, the train never reaches the next station. That is a big risk.

This blog is written because of the latest topic in the Bloggers Club of the Ministry of Testing community.

About the author

I currently work as a Test Automation Consultant at b.ignited. Here I work for different clients in different industries to help them start and speed up their testing cycles

I’ve been testing software since 2000 when I became involved in testing telephone applications and hardware. Since then, I’ve been able to expand my experience by testing a variety of embedded, web, mobile and desktop applications. I have used various development methodologies from waterfall to agile.

I consider myself to be a lifelong learner.