Shimin asks, What do you mean by “peer review”? Here are my definitions:

Peer review. An author asks a peer to read, comment, and critique a work artifact. If the work artifact is code, the reviewer will read the code, and may even develop and run some unit tests to check that the code works as advertised.

Walkthrough. An author presents the work artifact to others. If the work artifact is code, the author walks through the code, explaining what this pieces does, what that piece does. If the author is like me, the author trails off in the middle of a sentence and says, “Oh no, that’s not what I wanted.” Or, “There’s the problem.” :-)

Inspection. An author requests the services of a moderator, scribe, reader/reviewers in a formal meeting. The moderator books the room, sends out the material. The reader/reviewers read the material before the meeting. During the meeting, the reader/reviewers take turns reading the work artifact out loud. The scribe takes notes of issues the reader/reviewers discovered in advance and during the meeting.

Let me know if you have other definitions, or other techniques that don’t fall into these categories. These techniques are useful for any work product. You may have to modify them for non-code work products.

I’m reviewing my students’ updated plans for their projects. One team originally wanted full unit testing on the code as it was created, but added (my paraphrase) “if the project is late, some unit testing will be acceptable.” I responded that the farther behind the project was, the more review and testing is required.

Here’s why. Projects get behind because the people don’t understand something. The more they don’t understand, the harder it is to create the product, and the more defects they introduce. This is not because the people are bad — good or bad development skills have nothing to do with it. This is a function of not clearly seeing what the system is supposed to be. If you find your project is behind, consider these options to help people see the system clearly:

• Hold peer reviews on every work artifact. I prefer reviews, not walkthroughs, but anything to put at least one more pair of eyes on the product is good.
• Inspect every defect fix. Yes, I do mean formal inspection, where someone reads the fix out loud.
• Full unit testing on every piece of code. The developer will understand his or her code when trying to test it
• NIghtly builds (more often if it makes sense). The faster the feedback to the developers about potential problems in their code, the faster you can decide what to do about the problem.
• Implement by slice. Instead of implementing the components of a system, implement just enough of a component to complete a given feature or use case. In my opinion, Big-Design-Up-Front doesnt’ work very well because the developers and architects don’t actually understand what they’re doing. This is not a competence thing :-); it’s an artifact of us as an industry not being able to fully articulate the requirements.

Some of you may be shaking your heads, thinking, “No, this will put the project farther behind.” Nope, it won’t. Instead of the illusion of progress, you’ll see the real progress. Reviews of healthy code speeds up the project in my experience. Reviews of sick and tired code reveals the work still remaining.

The problem is you won’t catch up. But you won’t lose any more time — not without knowing you’re losing time.

I seem to have a vision theme happening this week :-)

How many kinds of review do you perform on your project’s work products? Especially with software projects, it makes sense to review interim work products, so you have some idea about how good the final product could be.

Sometimes when I ask project groups about reviews, they physically recoil, and say, “Oh no, JR, there is NO WAY we are taking the time to review things. Reviews take a long time and we just don’t have that kind of time to spend on reviews.”

Well, if you’re on a strict-schedule project, you don’t have time to NOT perform reviews. You don’t have to use Fagan-style inspections, the most formal type of review. You could use walkthroughs, pair development, or peer desk-checking. Each of these techniques are low-time investment and higher return than no review at all.

I like walkthroughs, where the author presents the work product to an audience, best for project plans and schedules. When I walk the technical staff through a project schedule, they have the opportunity to point out dependencies I didn’t know about. When I walk the senior management through a project plan, they can tell me whether they agree with the project vision and release criteria.

Pair development is great for requirements, designs, code, and tests. Pair development works best with one keyboard, one mouse, one screen, and two people. If you’re not sure how to make pair development work for you, see Laurie Williams and Robert Kessler’s book, “Pair Programming Illuminated”, ISBN 0201745763. When you’re done with the work product, two people know it intimately and have discussed the alternatives.

I find it difficult to use strict pair programming for writing English, because I don’t always know what I’m going to say when I sit down to write. For me, the act of writing a natural language generates more ideas. Writing a computer language is different. So, for English language work, I use desk-checking techniques.

Desk-checking, where someone else reads your work product and tries it out or comments on it, is another great technique for finding inconsistencies in writing (whether it’s code or a natural language). Desk-checking, because it is so informal, depends on the expertise of the person doing the checking. Someone who’s familiar with the work product and has the time will do a good job desk-checking. Someone with less expertise, or is having a bad day, or is tired will not perform as good a review.

In any case, no matter which review techniques you choose, consider which techniques are useful when for your project. The more eyes on intermediate work products, the better the final product will be. (And if you have any ideas about how to review blogs *before* they’re published, let me know :-)