Update [2008-12-31]: I posted the list of code review tools as promised below.

I tweeted this article on Five Reasons to Do Code Reviews from CIO.com last week,and realized that there are much more than the five reasons they give. So I came up with 20 more over the rest of the day. This is a collection of those tweets, with a little more detail given here.

Code review reason 1: Feedback comes back fast enough to give you whiplash. Since code review is done after coding and before integration or system tests, developers don't have to wait as long to get feedback on code quality. By providing specific, timely feedback, developers can adjust their coding practices to avoid common mistakes.

Code review reason 2: Find more bugs than testing alone. This is obvious: Testing finds bugs. Code review finds different bugs. When combined they find more bugs than you would otherwise remove before shipping to customers.

Code review reason 3: A million monkeys sometimes produce valid syntax, even if it doesn't make any sense. Compilers can't catch this.Sometimes you'll make a syntax error that produces valid syntax so the compiler can't catch it. The classic here is in C, = (assignment) versus == (boolean equality operator); in this case most compilers can issue a warning but there are other examples. A code review will catch this error quickly, but finding this during testing can be hard to track down.

Code review reason 4: Find and kill bugs where they live, instead of finding turds and having to track them back to the nest. When you get defect reports from a code review, you have in-hand the exact line number and problem description. When you get reports from system test or (horrors!) a customer, you get — at best — a reproducible set of steps to trigger the bug. It's then up to you to work backwards to the actual defect in the code, which is often time consuming, especially since the code may have been written weeks or months earlier. (See reason #1.)

Code review reason 5: Indoctrinate the n00bs. Code reviews are an effective training tool. First, new software engineers who participate in code reviews get to look at code produced by other engineers and thus get a feel for the coding standard and documentation style. Second, inexperienced engineers will get feedback on their code before they have a chance to infect the system with inferior code. (Because we all know that the code we wrote 10 years ago probably sucks — unless we were fortunate enough to have it reviewed by more senior engineers. If you haven't already been coding for several years, keep in mind that everything you're writing today probably sucks but you won't be able to acknowledge that for another few years; see reason #6.)

Code review reason 6: Uses developer egos to boost quality of code from the beginning. The theory here is that because developers know their code is going to be publicly scrutinized by a group of peers, they will take extra care in coding to avoid the embarrassment caused by having others find all kinds of bugs in their code.

Guest contributor @kyletolle: [Code review reason [7]][]: Explaining code makes sure they understand it well. Will fix the "Uhh, b/c I always do it that way" remarks. After you have to answer this question a few times during a review, you'll probably ask the question of yourself while coding. (See reason #6.)

Code review reason 8: Makes testing go faster. Heck, it makes the entire development cycle go faster. There are multiple root causes for this. First, since code review finds and fixes defects at the site of the defect (see reason #4), less time is spent fixing these defect. Second, fewer bugs are found by testers so they spend less time writing up issues and the engineering team spends less time tracking and managing issues. Third, testers don't have to re-run regression tests so many times because fewer release candidates will be needed.. Last, it is less likely that testers will be blocked waiting for fixes to bugs.

Code review reason 9: Fewer angry phone calls means happier tech support staff. Proof: Fewer bugs in shipping code (see reason #2). Customers not disrupted by bugs as often. They don't get angry as often. So when they call, it's with songs of praise. QED. (Ok, maybe that singing part isn't true, but you get the picture.) To prove this from another angle: if you're spending less time fixing bugs, you can spend more time implementing features that customers are requesting.

Code review reason 10: (Anti-reason) You'll pay more sales commissions because you'll be selling more product...wait, that's a good thing! When customers sing your praises because your product is so reliable, it's easier both to sell to new customers and to sell more product to your existing customers. Sure, your sales commissions might go up, but I've never really heard anyone complain about this too loudly.

Code review reason 11: There are tools that reduce the annoyance factor of old school review processes. After I tweeted this, @kyletolleasked for some recommendations. I will follow up this post with several tools that I've found. Stay tuned. (Look at my timeline starting here for now).

Code review reason 12: There's zero risk. Even not-super-effective reviews beat testing. If I spent a little time I could probably dig up some published research to back this up. But my personal data says my personal code reviews are about four times as effective as unit testing. So even if I perform a half-hearted review, I'm still going to be more effective than testing. (See reasons #2 and #4, also keep in mind reason #5 which doesn't have an immediate measurable effect.) There might be data out there that says code reviews are a waste of time. Flying reindeer might also exist.

Code review reason 13: (Anti-reason) Testers bored from not finding as many bugs... Oh yeah! They could focus on stress/perf tests. This would be a good problem to have...

Code review reason 14: Reviewing code is good practice for reviewing code. You'll get better. Your team's review effectiveness will improve over time. This means that the long term risk of failure is even lower than the short term risk (see reason #12 for why the risk of failure is zero or very close to zero).

Code review reason 15: It's a great way to build a really useful code review checklist. This is kind of stretching, a useful code review checklist doesn't really matter to the customer. (I should probably come up with a couple of bonus reasons to account for the "artificial fillers"... Hey, I tweeted this during the 3pm slump before my afternoon cup of tea.)

Code review reason 16: Out on a speculative limb: better staff retention because developers spend less time fixing annoying bugs.I'm not sure about anyone else, but I've stayed at a job that was otherwise not-so-great because of the quality of the team I was on and the people around me. Being part of a well-oiled machine feels good. It's motivating to go to work everyday knowing that you're going to produce a high quality product and your coworkers are there to back you up.

Code review reason 17: Reduces schedule risk because product quality is higher as it enters downstream phases. Your testers won't get blocked as much (see reason #8) and testing won't drag out. Since you get feedback relatively early in the schedule (see reason #1) you have a good idea of how long testing will take.

Code review reason 18: Feedback (especially from peers) at the source level means you will stop making the same mistakes over and over.(See reason #6.) This also stems from the fact that each engineer will have data in-hand about the types of defects he makes and he can come up with ways to prevent this defect from happening to begin with. And this is really when the magic occurs: when you can start thinking about preventing entire classes of defects.

Code review reason 19: Improves the quality of documentation / comments as well as executable code. (See reason #7.) Developers will include better comments to avoid having to answer too many questions from reviewers. If reviewers are looking for inconsistencies between comments and code, this is extra motivation to make sure that code documentation is up to date. Lastly, I suspect that overly complex code will become scarce since this will be scrutinized and questioned more than simple code passages.

Code review reason 20: Customers won't find as many bugs in their soup. This is maybe redundant to reason #9, but helping customers is why we exist, right? So I'll allow this one to stand and — like I said above — I'll work on a couple of bonus reasons to add to this list.

[Code review reason [7]]: http://twitter.com/kyletolle/status/1076701951