You've seen the advert (except the original URL has gone AWOL):
This is an image for the book from SmartBear (in lieu of the missing advert):
(Converted to 'Community Wiki')
Not so good. I just got it. I was hoping to see different techniques and research, but it really wasn't that at all. It was a small paper bound book with compact text and charts that didn't mean very much.
You'll do better with looking online for Peer Code Review techniques and practices.
It's been a pretty good coffee mug coaster for about a year. It reminds me that we really should be doing more peer code reviews.
I've got it and I'm reading it now. For such a small book, it looks like it's a pretty complete guide. It covers five types of reviews (including pair programming, which I absolutely love that they're calling peer review), the social effects, questions you should be asking, and what measurements are useful to improving software. It's a decent guide if you don't have time to scour the net yourself for the same information. Overall, I'd say it's worth more than I paid for it. :)
UPDATE: As a follow-up, I just wanted to mention that I did start getting some marketing emails from the company that produced this book. I personally don't mind targeted advertising (I did show an interest in the kind of products they make), but I know many others don't feel the same way.
It's worth the price, but if you are really serious, this is the book to get:
http://www.amazon.com/Handbook-Walkthroughs-Inspections-Technical-Reviews/dp/0932633196
The one you mention is, of course, a promotional item for their software/system.
This is the best book I've ever seen on Peer Reviews: Peer Reviews in Software: A Practical Guide, Karl E. Wiegers.
Who's requested the book?
I have.
Who's read the book?
I've read some and thrown it away.
What are your impressions?
Text-book style. Informative, but boring.
What was the best thing you learned from it?
One can be both cheap and free.
Were there any horrible mistakes in it?
The sales pitch looks just like a used paperback.
How can I resell it to my boss? ;)
Great little book ... I'm surprised more places don't use peer review ... want realistic estimates to completion? Try peer review!
Wanna find out who's naughty and nice? Peer review.
Who's stuck?
Lots of justification if you're trying to champion a new practice.
Regards, Bill Drissel
(I have decided that I'm not not keen on the way Community Wiki only shows the person who last edited an entry. It would be good if the original author got credit as on a regular question, even if there is no reputation tied to it.)
I've read a good bit more of the book now. I like the two review chapters, one looking at a number of studies of code review and the other a more detailed one looking at the use of the Smart Bear tool at Cisco. The study on eye movement on trivial (20-line) program snippets was interesting.
There are some interesting bits of information lurking:
The bit that concerns me is the 200 lines part. How are the lines measured? Much of the code I work on has files that are multiple thousands of lines long (20,000 in at least one case - and that is not a generated file). If I need a code review of 20 lines edited in scattered places in the code, is it a 20-line review or a 2000-line review concentrating on 20 lines? I suspect it is more nearly the latter - or should be. To the extent that we treat it as a 20-line review, we are missing context.
(I'd be the first to accept that the code should be improved - I'm still struggling to get people to change the function definitions from K&R to prototype notation. That's the problem with 20-year old code. It is almost enough to make one despair.)
As the (ahem) author of the book, I appreciate the comments!
:-)
I've posted my review of Best Kept Secrets of Peer Code Review on my blog http://dlairman.wordpress.com/2009/05/19/review-best-kept-secrets-of-code-review/
Is there any pdf version available? The don't ship it into my country :(
Just the mere title says it all!.. I believe that besides every project having requirement specs, there should be coding/naming specs with an initial meeting to make sure everyone's on the same page and periodic reviews to make sure no one has strayed too far away!