Code Review for Solo Programmers

Posted by Robert Merrill on December 12, 2012 under Process Improvement | Read the First Comment

If you write most of your software alone, like I do, you have this problem. There’s no one to review your code.

Actually, there is. I learned about them from a discussion on the Madison Area Software Developers’ Meetup mailing list.

You can also get code reviewed on A subscription is $12.95/month. It’s not so good for browsing through code to help learn, because the code reviews are by technology, and are listed under the specific question rather than lumped all together. But EE has been a good place to get answers to technology questions in general, especially because it’s moderated well, and questioners have to tell which solution actually worked.

A few thoughts  on code reviews in general:

  1. For maximum effectiveness, use two or three reviewers. The second reviewer will spot half again as many issues; it’s amazing. The added impact of more than three isn’t worth the added time.
  2. Don’t try to review too much in one session. Sessions should go no longer than an hour—two at the outside. That includes both individuals reading code and the review read-out meeting itself.
  3. Require reviewers to go through the code by themselves, in advance. Use a consistently line-numbered version to make it easy to log issues and merge them up later.
  4. Over time, you’ll establish a metric of how much code can be reviewed in an hour or two, making it easier to chunk it.
  5. The meeting should be solely to read out issues. Reviewers should have already reviewed the code and made their list of issues. How to resolve issues is up to the author’s discretion, but should happen apart from the meeting. “Committee of the whole” problem-solving is highly tempting & wasteful.
  6. If the author feels “on the spot” leading the actual walk through the code, it’s OK for someone else to do it. Just make sure it’s clear that there’s someone recording issues and merging duplicates as they’re read out, and that it isn’t the author. They need to be able to listen and ask & answer brief, clarifying questions related to the issue itself—not the solution.
  7. Guard the review scope zealously. If the review surfaces broader design or architecture issues, set up  another round of review.

You can review any kind of document this way, not just code. It seems time-consuming, but in terms of defects detected and resolved per hour, it blows away any other QA method I’ve ever seen, especially manual-test-and-fix. I didn’t invent this. It’s called Gilb Inspection. I’m sure they’ve done more with it since I was trained on and used it a dozen years ago.

We had testers complaining of boredom.


  • Zekai said,


    Great job!!

Add A Comment