Fourteen tips
to better your PSPSM
Tip #2
Daniel M. Roy
(President STPP, Inc.
SEI visiting scientist and
transition partner)
Abstract: Fourteen tips are proposed to better use the PSP framework so that
improvement is made easier and PSP is routinely used on the job. Tips for PSP
support tools and about expanding the PSP to small teams are added to make the
transition to Team Software Process (TSP-SM[1])
even smoother.
2. Better your defect log
My students often have difficulties measuring the time spent fixing defects accurately. I had the same problem when I took the class from Watts himself in 1994. I propose a little trick to make life easier here. Instead of entering the date in the date box on the log, I enter a time stamp (fig. 2-1). The idea is to enter the time stamp as soon as you know something is not right. Then, go hunting to find and fix that bug. When you re-enter the defect log to completely fill the defect entry after the smoke has cleared look at the time stamp. This will help you accurately report the real fix time.
I find that useful since I am still better at logging start time than stop times…At least the time stamp reminds me when I started the hunt. On the job, a tool should do this, and automatically compute find and fix time for you. Such tools are in the works. More on this later.
Figure 2-1: tricking the defect log
Incidentally, never forget that what the PSP calls “fix time” really is “find and fix time”. I think the PSP 0.0 tutorial is quite clear about this but I am always amazed to see how often this simple but major concept can be misunderstood, even by student PSP instructors.
Now, I have observed another disturbing trend in the data. Total defects injected seem to go down as class progresses. It is often seen as a good sign. After all, aren’t students supposed to improve? Hopefully they do! Careful analysis does show this but it also shows something else: defect logging fatigue. As so better said by Beizer quoted in tips 1, there is no shame in making errors. The shame is in leaving them in the product.
Watts often reminds us that we goof because we're human. Discipline can help us catch our errors earlier, that’s all. Now, Einstein argued that too much discipline makes the brain less useful than the spinal cord. But Vic Basili reminded us in his introduction to Watts’ book on PSP than discipline does not mean hitler youth. It is regular practice to improve one's skill. We certainly do that with PSP and I do see a reduction in reported defects that can reach 50% over the 5 elapsed weeks (two weeks class work) of the SEI course format.
And that worries me.
One on one analysis nearly always shows that injection rate was not really reduced. Engineers inject about 1 defect (of all types) every 10 LOCs from detailed design to unit test. I've seen this with all levels of expertise (except a candidate PSP instructor from Motorola U who had been teaching algorithms the month before the class!) with all cultures on 3 continents.
Let's not forget that reviews are not defect prevention techniques. They are defect detection techniques. Causal analysis and rewiring of the neurons may come, but later. Claiming less injected defects is psychologically damaging. We goof because we are so much smarter than this pile of silicon that will blindly do what we said and not what we so obviously meant. Discipline does not (hopefully) make us less smart or less human. We may nip bugs in the bud and not report them, we may catch more reading back what we just wrote and not report that, but the synaptic S/N ratio is the same and I would be worried to see reported injection rates diminish.
Of course, each rule has an exception. A drastic reduction in error rate is normal with students who are rusty in their programming language. But these are not supposed to be taking PSP in the first place! Defects can also be caught so early, or indeed the neurons have been so well re-wired (or we are doing the same stuff that we’ve done a week before) that defects don’t show up on the radar screen. These are the only valid reasons for total defect rates reductions. Incidentally, I fully expect to see unit test defects drastically reduced from program 1A to 10A, but that is another story that I will tell with tip # 6.
Now, some icing on the cake. During post mortem, I suggest that you perform a causal analysis. Some students even enter a code in the comments (Omm for omission, Educ for Education root causes, Trans for transcription errors such as between design and code, etc.). Perhaps this should be another field in the defect log. In any case, I think it is good practice to do this causal analysis when data is still fresh in your mind. Actually this subject leads very naturally, to the systematic logging of all lessons in an extended version of the PIP which is the subject of the next tip.