Slashdot Mirror
Code Reviews vs. Pair Programming (mavenhive.in)
An anonymous reader writes: I've spent nine years working in teams which religiously follow pair programming. I'm used to working that way and appreciate the benefits it brings. We didn't have the luxury of pair programming all the time in my last project. This required us to do code reviews to ensure the quality of the code we delivered. This post is an attempt to consolidate the upsides and downsides of doing code reviews instead of pair programming in my three months of experience.
(Going anonymous)
You are likely running this through a cultural filter.
The Indian teams that I have worked with are a lot more about huddling around a computer working things out, than the typical US approach of developer with headphones collaborating a couple of times a day. Different cultures do things differently.
Looking at *real* salary information between two geos (Bangalore and Silicon Valley) comes out roughly as follows.
Architect level 2:1.
Junior level 5:1
You can have pair programming for junior staff and still have a very strong cost advantage in India. That cost advantage plus a cultural tendency would make pair programming fairly easy to apply.
Not making any comment about the quality of code or quality of engineers on either side of the pacific...
Watching someone else code is the most maddening thing. They always seem to take the long way of doing something; use the mouse and doing eight clicks where a keyboard shortcut would do, etc. I do my best to not watch people code when I'm trying to help them. I would have killed someone years ago if I did that full time.
-SaNo
A proper peer review process is far superior. Review your plan with your teammates. If you're working with components that others work on, make sure they are part of the plan review. Once all questions are answered, put your headphones on and go forth and code. Rely on unit tests to catch the obvious problems, rely on integration tests to catch less than obvious problems, rely on QA to catch what your integration tests miss. Use linting, static code analysis, and other tools like Sonarqube to identify potential problems within your code that may not manifest themselves under day to day usage. Voila...
Is it perfect? Of course not. Will your software be 100% bug free? Of course not. It also doesn't solve problems related to lack of intelligence or experience amongst your teammates, and it doesn't solve problems related to lack of foresight from management who impose impossible deadlines or who close deals with customers that include features which don't exist. But the team will still be more productive than if they had to share computers and work in pairs. Programmers need focus and pair programming will ruin any focus you could have.
I'm god, but it's a bit of a drag really...
Even the early academic studies (PDF warning) of the effectiveness of pair programming found that you didn't quite get as much out of a pair team as two individuals working independently. However the code quality is generally a lot better in terms of correctness or readability.
If you have a few individuals who are new to an organization or becoming acclimated to a new project they've not worked on previously, pairing can make some sense. On the other hand if you've got a rock-star developer that's head-and-shoulders above the rest, it's probably not worthwhile to pair them with another person.
In our organisation, we have teams of six people that work together on their sprint. QA staff are included in this team.
On major features, the team code reviews the feature together in a special session. Roles are assigned. The author is present, a reader (who is not the author) reads the code. There is an arbitrator who decides whether a raised issue gets fixed. This arbitrator role is rotated through the team on an inspection by inspection basis. Finally, there is a time keeper role who moves the conversation to a decision if one topic is debated for more than three minutes.
This process typically finds a humongous number of issues. It takes us about 4 hours of applied effort to discover a bug in pure functional testing. This process discovers bugs at a rate of 1.25 bugs per man hour of applied effort. So if you have five people in a room for one hour, you have applied 5 man hours. You'd expect to find 6-7 bugs. If you include all the stylistic coding standards bugs, this is typically 10-15 bugs per hour.
So while on the surface it looks expensive to have all those people in a room talking. The net result is that it tends to accelerate delivery because so many issues are removed from the software. Better still, the review occurs before functional testing begins. This means the QA staff on the team can direct their testing at the areas highlighted by the inspection process. This further improves quality
It's true that about 50% of the ossies are stylistic issues. But usually we get 1 or 2 bugs per session that present a serious malfunction in the program. The rest could be problems under some circumstances or minor faults.
Team reviews are vastly, vastly superior to pair-programming. There really is no contest.
This is nothing new.
The effort of every individual in a group of people has been measured by Ringelmann in 1914, for army's purposes.
Here is the original article: http://gallica.bnf.fr/ark:/121...
And the results are (number of people => measured effort)
1 => 100%
2 => 93%
3 => 85%
4 => 77%
5 => 70%
6 => 63%
7 => 56%
8 => 49%
This is called "Ringelmann effect" or more recently "social loafing".
As you can see, 8 people produce the same amount of effort than 4 individuals.