I'm currently trying to pitch code reviews ( to improve code quality) to my manager. I am getting some push back, due to the belief that code reviews aren't required when you only have senior developers (and no juniors).
What are some good arguments that I can make for Code Reviews, even though our team is composed only of Senior Developers.
You should do code reviews because even Senior Developers can be idiots. Code reviews allow people to see how things are being done from each other's perspective and how people are tackling certain problems. It's a great way to share ideas and knowledge much like telling history stories around a campfire which is usually the code printed out being set ablaze. People who want to maintain the illusion of being "Senior" will push back because they don't want their idiocy to be exposed.
"Sir, do you think someone would publish a book, even from (to pick a recent & highly regarded author) JK Rowling, without it going to at least one editor first?"
Only probably not so sarcastic.
Education and reducing your truck factor.
Code review can be a way of letting others on your team know how a particular piece of code works. If the developer is unavailable, one of the others can pick it up more easily.
Diffusing new techniques would be another good reason to do it.
There must be those who are more experienced than the other.
Aside from that idea, even a "junior" (relevativly speaking) looking at a "seniors" work can bring up questions. It's a teachable time -- not just for the one being reviewed but for the one reviewing....
Because even Senior Developers make mistakes. Sell it as everyone doing a double-check on everyone else. And hey, if they're all Senior Developers, then the code review should be very quick and easy because they're all so awesome, right? ;)
Code review is required even if you are a senior developer. Anyone who says otherwise is just arrogant (or afraid that they won't be thought of as "senior" after all). We are all human and we make mistakes. The arguments that you can use for code reviews are the usual ones:
All developers inject defects into their code, even senior ones. Code reviews will improve product quality and development productivity by reducing the number of defects that make it to Test (or otherwise beyond the development cycle). Additionally, code reviews can be a learning experience for all the developers in your shop. Finally, chances are your company won't ALWAYS have ONLY senior devs on staff, so getting into the habit of doing code reviews now will be easier than trying to implement the process later with both junior and senior developers on staff.
"Senior Developers," who perhaps understand the power of the language at a deep level, often use advanced, esoteric, obscure productions to achieve concise, elegant code. Plus "Senior" often means "spent years on the project." That means that he has enough local knowledge of structures, conventions, and so on to take shortcuts.
I'm all for elegance; and I take shortcuts all the time.
But what happens when I move on? Who is going to maintain my code? You know it ain't gonna' be another "Senior Developer" -- he's too busy developing new stuff (and adding esoteric idiom and obscure shortcuts as fast as he can. Why is he doing that? Because his project is way behind: that's why he was shifted onto the project in the first place).
No, one of the new kids is going to be maintaining the code, first spending quite a few weeks just learning which spaghetti strands lead somewhere; and which ones are dead ends.
Is your company going to stand for three months of learning time before a bug can be fixed?
Smart software managers take software reviews very seriously. Design reviews and code reviews are indispensable, imo. A code review is almost the last chance you have, before QA, to fix bugs before the product ships.
One of the (many) tasks of the folks reviewing the software is to question obscure spots in the code and, if they can, insist that those spots be fixed. Or at least heavily commented. That saves tons o' bucks -- you can't imagine how much -- over time. It can even save a project: I've helped to rewrite projects that were abandoned because (1) the original guy wasn't around any more; and (2) nobody else understood how his code worked.
So please consider mentioning to your manager that he might find it a lot less embarrassing in the long run if he spent a couple of man-weeks now on a code review; and avoided spending a couple of man-years later rewriting stuff.
In my opinion, anyone who says code reviews are a waste is too ego-involved ior foolish ior ignorant ior stupid to live.
There used to be a maxim: "there's never enough time to do it right, but there's always lots of time to do it over."
-- b
The best argument you can make is to show your manager examples of code that should have been reviewed, and explain how a review would have helped the code.
You can probably bring up some mistakes those senior developers have made and mention "a code review would have caught them."
You probably want to start with your own, but no harm in including others as well.
I think statistics might make a good case for code reviews. There are a few studies mentioned in Code Complete, 2nd Ed. (Ch. 3, p. 470) that show an average "defect detection" rate of 60% when formal code inspections are performed.
I also vaguely remember reading somewhere that the effectiveness of code reviews was one of the main reasons why pair programming was made a core principle of eXtreme Programming. "If code reviews are good, let's do them all the time," was the reasoning.