Summary

It's obvious from some of the defects that slipped past my reviews (items which are blatantly in the review checklists, such as := vs =, etc) that I'm far from expert at doing them. Even so, the results are very positive: only one error in test from both Eiffel and C++, and more defects caught earlier; the defects/hour caught by the design and code reviews are significant.

I'm not sure I'm convinced that code review before compile is the best use of time-- after all, the compile phase still has a much higher defects/hour detection rate than either inspection, and it may be worthwhile to compile first, getting the easy compiler errors, and then peruse the code by hand.

On the other hand, the process of inspection is also one of setting up habits, and I should certainly cultivate a habit of precision in coding; for several years I have been operating under the "code like mad and fix it later" philosophy, a philosophy which has cost me dearly in poor design decisions and imprecise coding. That's really unacceptable, and perhaps inspecting prior to compile is one way to train myself out of the habit.

What made me happiest about this lesson is that, while previous aspects of the PSP have indeed helped me analyze and predict my performance, the inclusion of inspections and early elimination of defects is the first part of the PSP to actually improve my performance. The defects/hour metrics as well as the yield metrics (not reflected on the project summary, but given by evalpplog) have shown me some concrete results of improved practices-- and that's very encouraging.

This lesson also marks the first time I've tried documenting design decisions in any form other than scrawling on paper, and I'm pleased with the results. While I certainly can't glorify dia as anything but a diagramming tool (it's far from a CASE tool!), it helped document design decisions-- which I believe is the focus for the next lesson.