The Mindset

It’s time for yet another insight regarding reviews. You probably know this is one of my favorite topics, so this should come as no surprise.

In my previous posts on reviews, I described different types of reviews, or more accurately different motivations for reviews.

In Are Your Code Reviews Effective? I described reviews designed merely for identifying functional defects. In Sharing Project Knowledge With Your Peers I discussed a common motivation for performing reviews: spreading knowledge regarding the project (its design, code, tests, etc.) among team members.

Truth be told: both these motivations could be served better if we change the goal of the review and define it as a mentoring platform. Such professional reviews will improve the product (by improving the reviewed artifact) and the skills of the developer at the same time. By doing so, we create a better setting for fewer functional defects and better project-knowledge transfer among developers.

But there is another type of review — one that is more “dangerous” the types mentioned above. Why? Because the motivation for a review of this type is often hidden. It’s the reassuring review.

Reassuring reviews are mainly for the reviewer. They are “designed” to reassure the reviewer that things are in control and to ensure that the reviewee is on the right track. There’s nothing really bad with this motivation as-is, but in a reassuring review this is often the sole motivation.

Let’s analyze some of the symptoms of reassuring reviews:

1. The review is always conducted by the reviewee’s manager

Many novice development leaders (and some experienced ones) find it hard to trust some developers in their team. Well, it’s not that they don’t trust their team – they just feel an urge to constantly check what their developers are doing. When reviews are done in this particular mindset the developer will immediately feel he is not trusted.

I’m not suggesting, of course, that a manager should not be involved in the work of his developer. But when the relationship between the two is based on reassuring reviews, the developer feels he is constantly being scrutinized. Such feeling is bound to prevent the developer from learning, building experience, and improving himself.

Professional reviews, on the other hand, are not necessarily conducted by the development leader. If the development leader is the one conducting the reviews, he does so when acting as a professional mentor. This fact places the review activity in the right context — helping the developer improve the product and gain additional experience. The purpose of the review is not to reassure the manager that the developer is doing a fine job. The purpose is working together to create improvement.

When the focus of the review activity is not the reviewer, it is much easier for the development leader to accept other approaches for conducting reviews. The notion of a professional reviewer, who is not necessarily part of the development team, starts to make sense.

2. Only novice developers are being reviewed

Many development leaders are tempted to review only the work of novice developers. This tendency goes hand-in-hand with the trust issue. After all, trusting the work of a novice developer is much harder. This is a sure sign of reassuring reviews.

If you think about reviews as a platform for personal improvement, the implication of such a practice is that most developers have finished their learning process. But in real life, professional learning is a process that never ends. Part of being a professional is to constantly challenge your work. And what better way is there to do that than having it reviewed.

3. Smaller segments are reviewed as time goes by

Since the sole purpose of reassuring reviews is to reassure the reviewer, it is only natural that if everything goes as planned the reviewer will find them less necessary as time goes by. The fact that the center of reassuring reviews is the reviewer makes this activity unnecessary after awhile.

If, however, we think of reviews as designed for the benefit of the developer, and if we accept the fact that professionalism is a process of continuous improvement, there is no sense in stopping the review activity. If the review activity is a platform for discussing one’s work and learning from it, it should not lose its momentum.

***

Reassuring reviews are extremely illusive. They create the facade of a good process. They increase the confidence of the reviewer, who is usually the direct manager of the reviewee, thus creating the illusion of improvement.

To be really effective reviews must focus on the developer. They should be designed to create ongoing improvement — to challenge his work in the positive sense. This challenge is the key to constantly gaining new knowledge and building experience. And that’s what being a professional is all about.

This entry was posted on Thursday, August 17th, 2006 at 4:56 am and is filed under Review, Code Quality, Professionalism. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.