This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: On Pair Programming vs Code Reviews vs Unit Testing
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
The problem with traditional code reviews is that they come too late. The best time to get feedback is as soon as you make a mistake, not two hours later (or four hours, or the next day). [...] backtracking is expensive.
Code review while pairing causes no interrupts because the reviewer is already devoted to the task. You get much more detailed review for the same reason. Nobody feels bad about fixing nitpicky stylistic issues right away [...]. Teaching and learning are more efficient; [...]
On a project I was on (medical software), where we did formal code reviews, we reviewed both the unit tests and the code. Without the reviews, the unit tests would have been mostly ineffective because the programmers just didn't think about what could go wrong with the code, and write the tests for that. (We ended up requiring a LOT of post-review changes to improve the unit tests.)
I can imagine that many projects with unit tests (written after the code, rather than test-first) but with no code review nor pair programming have poor test coverage. Adding code reviews to such a project would likely turn up many bugs that the unit tests didn't catch. This doesn't mean that unit tests per se are not effective, it just means that many programmers need to improve their unit-testing skills. (And reviews or pair-programming are two ways to improve those skills.)
Test-Driven Development (TDD) forces developers to develop their unit-testing skills, and combining TDD with pair programming or reviews will make the unit tests even more effective, as the team members offer feedback and ideas to each other.
Pair programming (PP) while doing test-driven development is the most effective combination of collaborative design, reviews, and unit testing that I've experienced. One variant of TDD+PP is "ping-pong programming" described by Dave Hoover here.
Previous Topic
