In last month's column, "Reducing Your Cost of Quality," I listed "structured personal reviews" as being a highly effective appraisal method. This resulted in e-mails from multiple people asking me about that topic. So this month, I will explain what I mean by this term, and explain how you can make your reviews effective.
What is a "Structured Personal Review"?
Peer reviews and software inspections have been written about and effectively used in many organizations over the past two to three decades. They have proven to be very effective in improving the quality of software systems before the testing process even begins. These methods have many benefits and any organization would be well served by them.
That said, they do have one large downside: Doing them requires the cooperation of others within your organization, especially management. If you cannot secure the support necessary for those methods, they cannot be done. This fact leaves many software professionals who wish to improve their quality performance with few options for getting started.
A personal review is just what the name implies: a review that is done by an individual on his or her own work. It is a peer review without the peer. It is an inspection where the author is the only inspector. Can you really review your own work, though? Many people have tried to do self-reviews and have found that it is very difficult to do them well. I know, because I did! I was reviewing my own work before I learned a structured personal review process, but rarely found more than 20% of my own defects.
The key to making a personal review effective is "structure." This column very briefly sketches the structural elements that helped me to quickly improve my own personal reviews from below 20% effectiveness to over 70% in a matter of a few weeks. I did this using the Personal Software Process SM (PSP) from the Software Engineering Institute (SEI), which contains the best example of a dtructured personal review process.
Knowing What to Look For
The point behind reviewing your work is to find defects in your work products and remove them quickly and easily. So doing an effective review requires that you know what you are looking for. How can you know what mistakes you made this time around?
The best predictor of the defects in your latest work is the defects that were in prior things you produced. We humans tend to be very consistent and when it comes to defects, we are painfully consistent! This consistency, though, means that we can harness the information we have from prior projects to guide us in doing effective personal reviews.
We need to build a record of our personal defect history. Most organizations use a defect tracking system, so you already have a lot of information to start with. Go through the data and glean out the defects that were in your products. Here is part of your defect history. I say "part" because it does not include the defects you removed during compile, unit test, and any other activities that happened before the defect logging started. It is a start, though!
To fill in the rest of your defect history, you will need to start keeping track of the defects you find on your own, whether it was during your reviews, compiling, or unit test. After a short time, you will have a pretty complete picture of the defects you commonly inject in you work. For each defect, you want to determine:
· What did you do wrong? Defect reports often describe only symptoms, but to be helpful during reviews, we need to identify what we actually did wrong. Was the condition on an IF statement wrong? Did you forget to initialize a variable? Was the syntax of a statement wrong? Was your detailed design faulty? Think about what you had to do