How can I introduce code reviews to my group/company?

I'm probably saying the same thing as others, but here's my take on the question... I am in a similar situation; I work at a company where code review doesn't take place. A colleague and I decided to implement code review anyway, so my advice from that experience would be:- Make it about learning about each other's approach to coding, about learning the cool tricks your colleagues know, and them learning the cool tricks you know. Sell it. Make sure your colleagues know it's not a code audit, it's a code review and it's not about the master checking the padowan's work; it's about passionate coders talking shop and helping each other to be better at their craft. Don't be afraid to criticise, but do be careful about how you go about it (this is almost an obvious thing to say I guess...!), I often find it easier to frame criticisms in the form 'why did you choose to do x, won't that y?' - that way you're not patronising and in the case when you're wrong you won't rub people up the wrong way. Find a calm, quiet room to do the code review in face-to-face. I can't emphasise the benefits of doing it face-to-face enough. There's far less room for miscommunication, it's so much more dynamic and useful. I actually found the first code review I had electrifying, but then again I'm a real geek :-) If you're still finding it hard to get buy-in (ouch, sorry that's a little too close to management speak...), sell it on the opinions of well-respected members of industry. I mean the obvious example is http://www.codinghorror.com/blog/archives/000495.html, but I don't think it'd be difficult to find many, many other opinions to the same effect.

The company Smart Bear Software, makers of peer review software Code Collaborator, will send you a free book called Best Kept Secrets of Peer Code Review http://www.smartbear.com/codecollab-code-review-book.php. The first chapter is titled, "The Case for Peer Review", and the book then contains several case studies of different companies using peer code review. The last chapter of the book is naturally aimed at selling you their peer code review software product. Perhaps this book would provide some insight and justification for introducing peer code reviews into your workplace.

I'd suggest by asking others to review your code. Lead by example. Once an open discussion of the quality of code is established, you'll find others will be open to joining in, with the desire to improve their own work. Of course, you'll also find some people who won't want to shine the light on their work. You'll probably have to just leave them be. Its the responsibility of management to get them to participate. And, if your code review clatch results in better quality software, your management should be interested in getting everybody in on it.

Will is correct, you start by shining the light on your own code and asking a co-worker to sit in on a code review for work you have done. You foster an attitude of openness and others of like mind will follow. You have to lead by example. There are many good places to get this information. I would suggest one of the agile methodologies e.g. XP, scrum

In my experience, successful introduction of code reviews require good tools to make the process as pain-free as possible. A tool that lets the reviewer see a diff of the code, with syntax highlighting, on their own machine, in their own time, should make code reviewing very efficient and straight-forward. If you need to print copies of the code and set up a meeting, you'll have trouble getting support from your team (at least we did). You can use a commercial tool (Smart Bear Software offers some, but I haven't tried them myself), or something homemade built upon diff tools. Also, I've found that there's less resistance to code reviews when everyone does them, vs just the seniors and managers reviewing the code. It changes the relationship into one of collaboration vs evaluation, and juniors (or even interns, as second reviewers) can gain just as much by reading your code than you can from getting fresh input.

Echoing what the others have said, code reviews need to be viewed as a learning opportunity by the developers and a quality control opportunity by management. It is important that you don't foster an environment where code reviews are looked upon as a bad thing where there will be personal attacks on the reviewee's character and skill as a developer. Code reviews are about ensuring that other people have a chance to see the code and hear from the author the purpose of that code in order to help ensure that it was implemented in the best possible way and that it accurately (or as accurately as possible) meets the requirements. They are also a good way of enforcing and teaching any code standards you have in place. One way to help management see the benefit is by showing that the code reviews found x number of potential problems in the code that would otherwise have been found by customers once the code shipped. If you are introducing the idea, definately lead by example. Use your own code for the first several code reviews so people get an idea of how they work. Also, don't be selective about who participates in the reviews. If you can, get the entire development team together as well as at least one QA person. (Having QA involved is an ideal and only works well if your QA group is made up of people who can read/understand code.)