Peer Reviews or Pair Programming, or Both?

Question

• Do you participate in code peer reviews or practice pair programming, or both?
• Have you been able to demonstrate an increase in software quality using these practices?
• What benefits and drawbacks have you observed in the course of practice?
• What hurdles to implementation did you face?

In my own case, our development team pursued peer reviews of a number of different software artifacts (requirements analyses, test plans, code, and so on). Peer programming was not even considered as an option.

The peer review practice was pushed down from the top, and the developers never bought into it. We had an external SQA group that gathered metrics from the activities, but the numbers were pretty worthless since the effort was half-hearted. After years of this being the "official" way to do things, the developers have come to collectively ignore the prescribed procedures.

Now there is less visibility into when bugs are getting interjected into the lifecycle. And not doing the peer reviews has led to increased specialization on the team...where no one really knows the requirements/logic of components outside their own specialized area of the system.

It would be valuable to know your experiences w/ peer reviews or pair programming, especially success stories.

Answer 1

Peer review should be MANDATORY.

You can read and find numerous articles and books that discuss different ways to approach this within various sized teams, but you seem to inquiring about experiences.

Personally, I think peer review should be made fun. Food provided and keep the atmosphere jovial. It really should be treated as a time where developers/programmers can learn from each other not a chance to judge (and we all know how every programmed seems born with an innate judgmental gene). I have tended to appreciate or assisted to organize reviews to be 1/3rd or 1/4th of the time as open. By that I mean when the group comes together and one person presents a project they are working or even reviewed which is not even related to the current project (I know this is difficult with deadlines but try for it).

Creatives usually get together to display paintings, designs, and artists they’re currently into in order to help facilitate inspiration. Realistically, inspiration should be the leading concept you hope to foster in a review. Secondary to that people just naturally notice things their fellow developers do which they have NOT noticed before. “Oh wow, so you managed to do that in a single line of code? Cool.” Getting developers inspired and motivated about what they do, what they're working on, and how they go about it will pay dividends more out than using peer review to establish pecking order and rank.

Finally, comes the actually “review” part but it’s an inevitable fact. Your better developers will see poor code and after enough reviews it’s time for the poor coder to either step-up or forget about it.

If you keep things positive and organized its usually a great experience.

Almost forgot to touch on pair programming. This is tougher to set-up. Obviously you can't have two of your weaker programmers working together or you might as well arrange a million monkeys with a million typewriters. Try to put a stronger person with a weaker on and offer incentives to both privately. Someone who is weaker should know that improvement could be rewarded (if they require such incentive) and the stronger programmer should know that real leaders start as good mentors. Make sure the weaker dev is typing though. Not vice-versa or it becomes a presentation and "yawn" someone might not gain anything by the experience.

Answer 2

When I was young and foolish, one of my first jobs was to build a parser to pull out certain fields in a long pdf file that was dumped to unformatted text. I knew enough to use some form of regex, but not enough about regex’s to do the job well. Several days later I finished the task, but in peer review I was crushed to learn that I could have done better and what I produced was trash. I learned how to do lexical parsing just to prove that I wasn’t an idiot, but lets just say that the peer review process sucked. I didn’t need a senior person to dance on my failures, I needed a mentor and I have reminded myself of that every time I have done a peer review.

I like peer reviews when we check the egos at the door. (This includes mine!) There is a finite amount of time in this world, and only so much that you can learn and do. Through a good peer review you can expand you knowledge and get more done in a shorter time frame. The problems arise when the things degrade into over anal syntax checking.

I have a few rules because of this. I don't peer review anything that we can automate. Run a spell check, and code beautifier. If you have something like FXCop available to you, run it, do what it says, or have a darn good reason why you aren't. Then we can look at how the code is put together, how it functions and things that we can do to improve upon it. In this way you get a different perspective on how to solve a problem and why someone thinks that way. Sometimes the other way is not really better, sometimes the new solution is fantastic and something you will use for the rest of you programming life. Once the review is done, that’s it, I’m not using it as an example against you. It’s yours to learn what you will from it. I will not manage by fear or threat, you’re a smart person and I’m going to let you show it.

Answer 3

The only directly related experience I have of either is of peer design reviews (a long time ago). And they sucked. If you read the literature, it was clear that they broke several rules of good reviews (jumping on people, focus on spelling, no clear outcomes etc. etc.) but it was all we knew.

BUT since then I have been involved in plenty of off-line code reviews.

Depending upon project they have either been mandated before check in to the "live" branch, or at some random point of time after. On 3 out of 4 projects they have been embraced, admittedly as a necessary evil initially, but later as a valuable input.

The benefit of any working review should be to make everybody write better code and gives even the best coders mentoring (be honest, do your hot shot programmers actually write readable code ?) Once you can persuade less experienced staff to say that they don't understand something - you're away. Some of the hot shots will huff & puff but the actual best ones will think about what they have written and actually change variable names or layout - and perhaps even add a comment.

The 4th project uses an imposed scheme reviewing 'at a random time' and the technical leads haven't brought into it as yet (broken team ?)

---

The two practices you describe are formal approaches. They don't work well for all personalities and groups.

Try something that you think your team can actually do and then see if it can be improved.

Once you have had that extra set of eyes on your code you won't want to look back

Answer 4

I've done a bunch of agile coaching, and to help people get over the "stigma" of pair programming, we call it "real-time code & design review". People seem to get the concept better you put it in those terms.

Answer 5

We try to make sure that no code goes into production without having gone through at least another pair of eyes.
Usually, it means we code review. We try to make it a habit around the team that reviews are an inherent part of writing code. You write it, then ask someone for an opinion.
Also, on projects where we have enough people available (are when the tasks are of right size) we try to pair programming.
I must say we have definitely seen an advantage to this. First of all, it's a great way to mentor junior developers in the team - when you review their code you get to show them what can be done better, and when pairing with them they get to see better ways of doing stuff, how experienced people think and even how to use the IDE better.
Also, it keeps the whole team in sync as far as knowing how the code looks.
And, furthermore, it simply increases everyone's joy and personal development - a team that is capable of talking and reasoning about code is a better team, a team that keeps learning and sharing.

Some things to watch out for:

• Make sure seniors let juniors program too when pairing
• Don't let people pair on small tasks, usually wastes time
• Watch how pairs get along (don't force a pair together)
• Remeber to reshuffle the pairs every now and then
• Don't let reviews bee an ego match - don't let people crush others

Answer 6

• Yes, our company uses peer code reviews. We conduct them as Over-The-Shoulder reviews and invite the team’s tester to participate in the meeting to gain a better understanding of the changes.

• There are definite benefits to code review as several studies have been able to demonstrate. For our company, it was evident that code quality increased as the number of support calls decreased and the number of reported bugs decreased as well. NOTE: Some of the benefits here were the result of implementing Scrum and abandoning Waterfall. More on Scrum below.

• The benefits of code review can be a more stable product, more maintainable code as it applies to structure and coding standards, and it allows developers to focus more on new features rather than “fire-fighting” bugs, and other production issues. There really aren’t any drawbacks if code reviews are conducted “right”. More on the “right way” below.

• Some of the hurdles to overcome while implementing code reviews are the idea that “big brother” is watching me and the idea that not having perfect code means torture and pain. Getting developers to trust each other is difficult sometimes, especially when it involves “pecking order” or the “holier than thou” attitudes and putting your hard work under a microscope. Trust is the key to resolving these issues. A developer must trust that they will not be punished by peers or management for mistakes in code. It happens to everyone. Make a note of the issue, get it resolved and move on.

Scrum One of the benefits of using the Scrum methodology is that a development cycle (”sprint”) is short. The time-frame of the “sprint” is determined by what works best for your organization and will need some trial and error, but really shouldn’t be longer than four week iterations. The benefit is that it requires the developers communicate daily and communicate problems early on in the project. This was initially adopted by our development department and has spread to all areas of our company as the benefits of scrum are far reaching. For more information, see: http://en.wikipedia.org/wiki/SCRUM or http://www.scrumalliance.org/ . As the development iterations are smaller, the code review process reviews smaller pieces of code, making the review more likely to find problems than hours or days of formal reviews.

“Right Way” Code Reviews done the “right way” is completely subjective. However, I personally believe that they should be informal, over-the-shoulder reviews. All of the participants in a review should avoid personally attacking the person being reviewed with statements such as “why did you do it that way?” or “what were you thinking?” etc. These types of comments diminish the trust between peers, leading to animosity, hours of arguing over the best/right way to code a solution. Keep in mind that developers do not think or code exactly the same, and there are many solutions to a problem.
Just a little clarification on over-the-shoulder reviews; these can be conducted via remote desktop sharing (pick flavor here), or in person. However, they shouldn’t be limited to the developers only. We typically invite our entire scrum team which consists of two developers per team, a tester, a documentation person, and product owner. All non-developers are there to gain a better understanding of the changes or new functionality being made. They are free to ask questions or provide input, but not to make coding decisions or comments. This has been effective as certain questions will be asked that may change the direction of the project as the initial requirements may have missed a scenario, but that is what agile is all about, change.

Suggestion I would highly recommend researching scrum and code reviews, before mandating them. Create the basic rules for each and implement them as part of your culture to achieve a better quality product. It must become part of your culture so that it is part of a natural process and integrated at all levels, as it is a paradigm shift from poor quality, missed deadlines and frustration to better quality products, less frustration, and more on-time deliverables.