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 🙂