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.
You have gone through nine years of pair programming and haven't shot yourself? The idea of pair programming itself is insane. I didn't know anyone actually did it.
...and it is rather simple.
Design > Discuss > Refine > Implement > Run code analysis
This can be done in any workflow and in pairs. You don't gobble up the time of two team members but you still get to discuss the most important part of the implementation. You can even do a light-weight review afterwards with a check list of practices to focus on.
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...
I wouldn't know a better way to destroy productivity than having people pair programming in a public space. How is anyone supposed to concentrate on their work or their coding partner while listening to the conversations of everyone else in the room at the same time?
There might be times when it's nice to have the second person helping pedal up a long hill. But you're certainly not going to double your speed or your stamina with two people on one bicycle.
Pair programming is like that. There are specific situations where it's useful, especially when you're dealing with a tricky algorithm or intricate business requirements. But much of the time, the second person is just dead weight.
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.
... I swear. Lean, SCRUM, XP, Agile, Waterfall, Kanban, Scrumban, TDD, BDD, Pair Programming, Code Review, User Stories... etc... etc... etc.
How about just be a responsible craftsman, understand the customer's requirements and needs, and implement your solution responsibly and with integrity? Whatever that means. If you need to pull someone in, then do it. If you don't, then don't. Christ, how complicated is this? It's one thing to be a junior developer and having to learn things. Fine. But an experienced software developer should not require constant canoodling to get their job done responsibly, with integrity, and with good quality. Is it really that hard?
I'm from a pretty old-school programming upbringing -- back when you were a "Programmer" or "Analyst" or "Programmer/Analyst". I'll tell you in those days... if a programmer demanded this kind of ridiculous hand-holding, canoodling, and process-implementation to get their job done... they would be fired. Plain and simple. This industry has become awash with process and tool zealots... while knowing the customer's needs be damned.
You prefer peer review or test-driven?
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Pair programming when creating new features: FAIL. Pair programming with the guy who wrote the original code when you find bugs: EPIC WIN