Sharing Project Knowledge With Your Peers
My Are Your Code Reviews Effective? post raised some fine questions. The most popular question regarding Professional Reviews argued that reviews conducted by a professional mentor will not provide the benefit of knowledge sharing that other reviewing methods seem to provide.
Knowledge sharing among team members is an important goal. Having only a single developer who knows the internals of his code and design is not a desired setup. However, the method for achieving such knowledge sharing should not be mixed with the method for reviewing the code.
Revisiting The Goals Of Reviews
Code and design reviews have two clear goals. The first is improving the product under review. The code and the design must be correct, but also maintainable and extensible as needed for that specific product. The second goal is at least as important: improving the skills of developers – building their experience in a guided manner.
The best way to achieve both these goals using the same resources is professional reviews.
Look For The Beneficiary
So, where did the knowledge sharing goal disappear to? It didn’t. But it really has nothing to do with reviewing the code. They are two separate activities. The best way to realize this is by looking for the beneficiary of each activity.
The primary beneficiary of a code review is the developer who wrote the code. He needs to understand how to improve his code, and build his experience along the way.
A knowledge sharing activity, on the other hand, should be focused on the developers who did not write the piece of code in question.
Therefore, the mindset in each of these activities must be different. Trying to merge these two activities will result in some strange mutation which has almost no value to any of the people involved.
The Solution: Knowledge Sharing Walkthroughs
Many organizations use code walkthroughs as a reviewing method. As such, this activity is close to being worthless. However, as a simple method for passing knowledge about the code and the design to the rest of the team, this is a great method.
With Knowledge Sharing Walkthroughs you can reach a group of developers at the same time and pass on the relevant knowledge about the code. A discussion in such a forum is also a great tool for promoting the other team members’ understanding of the code. This method is by far more effective for knowledge sharing than one-on-one peer reviews.
For walkthroughs to be effective as a knowledge sharing method, the code presented in them must already be good quality code: it must be simple, clear, well-designed, well-structured, and readable. It must also be correct. In other words, it should already be reviewed. Presenting good code in a walkthrough session is a mandatory condition for successful knowledge sharing.
Remember that walkthroughs should have nothing to do with reviewing the code. The best method for improving the code and the skills of the developer is one-on-one sessions with a professional mentor. Knowledge Sharing Walkthroughs are great for spreading knowledge of the product’s quality code throughout the team.
The two activities have different goals and different beneficiaries. Do both, but keep them separate.
May 2nd, 2006 at 7:06 pm
I think the reason I don’t see eye-to-eye with you on your “professional reviewer” concept is that you have a very very very low opinion of software developers. Why else would you say, “The focus of what I suggest is on mentoring developers to help them become professionals”?
If your mentoring scheme is only intended for interns, then I have no problem with it. But if you believe that developers (people who haven’t graduated from programming to management or mentoring or consulting) aren’t bright enough to go over design issues during a code review, then I think you could not be more wrong.
May 3rd, 2006 at 1:26 am
Hi Rufus,
Nothing could be further away from the truth. Please refer to my article The Making of Professionals. I have nothing but respect for the capabilities of developers. Otherwise, I wouldn’t have suggested that they can become professionals.
Most developers are capable of mastering design and coding. Most of them want to do just that. But the fact is that a great part of the code written today is far from being high quality code.
The reason is lack of supportive environment and lack of guided experience. Peer reviews are not an effective method for promoting this.
If 20% (for example) of the developers have already mastered design and coding, they are capable of being good reviewers and mentors. But the other 80% still need to build their experience. With arbitrary peer reviews, they generally won’t be able to do that.
Lidor
May 3rd, 2006 at 2:10 am
One more note:
Most people are not born professionals. They have to grow to become ones.
This cannot happen by itself. Merely having X years of "experience" is not enough.
The role of a professional mentor is to nurture professionalism, not only for interns, but for anyone who needs it.
Lidor
May 3rd, 2006 at 7:41 am
“a great part of the code written today is far from being high quality code.”
“If 20% (for example) of the developers have already mastered design and coding, they are capable of being good reviewers and mentors. But the other 80% still need to build their experience.”
Thanks. You pretty much proved my point. You clearly believe software developers suck at developing software.
And clearly your mentoring/nurturing scheme is not intended for skilled developers, it’s for people who don’t know how to design and code.
May 3rd, 2006 at 8:44 am
Rufus,
I am sorry you feel this way. I never said I think “software developers suck at developing software”. I do think that we (as an industry) still have a long way to go.
Compared to other industries, our products are not of high quality. There are always exceptions, but I think most people will agree with that statement. Just think of common software products you use (not the ones you create). Are you 100% satisfied with them? If you are, you are lucky!
There are many reason for that, but the part of the developers cannot be ignored.
This does not mean that most developers are not talented people. The opposite is true. But being a professional developer is something one needs to learn. Universities and business organizations are not doing enough to promote this professionalism.
The problem is not with the developers, but with the environment that does not systematically encourage professionalism.
Lidor