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

Question

I work for the company's research team, which is pretty selective in hiring. Having said that, we all tend to work on different projects, so it is very easy to cut corners because no one is watching. I know that I have done it when time crunched.

Every now and then, I have to work on someone else's project. Whenever this happens, I inevitably see a couple strange pieces of code that really should be improved upon.

On the other side of the coin, before joining this team, I worked for another team that was comprised mostly of people that had never written one line of code prior to joining the team. This team had NO code review system.

What kinds of things can I do to implement code reviews? I'm not a manager, in fact, I'm the newest person on my team, but I'd like my team to improve our code.

Edit: Thanks for the answers. How would you go about getting management behind the code review process? To me, it seems that my group isn't too bad right now, but other groups in the company are in desperate need of a formal code review process!

Any other suggestions? I'm still trying to come up with answers!

Answer 1

Code review has to be a collaborative process. The the best place to initiate a discussion on it is with the entire team, and the best place to start is with your own code.

I find that if their introduction to code review is "I saw this code of yours and this it would be better if..." they'll just get annoyed.

Instead go in with "This is my code, how would you improve it?"

That way they've had the opportunity to give feedback first, and will respect it more when returned.

The most common barrier (in my experience, anyway) is some developers always think that their code is somehow inviolate. The irony is that, while often really good code, theirs is often that which needs peer review the most.

Answer 2

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.

Answer 3

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

Answer 4

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 Jeff's post on the subject - 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.

Answer 5

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.)

Answer 6

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 upon request.

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.

Answer 7

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.