Code Changes During the Transition Phase

We just said that we want to keep the code changes to a minimum during the Transition phase. But the fact is that there will always be some changes. Even if your customers have used the iteration releases regularly, they will exercise the final product much more. And they will uncover some new, and possibly serious, defects.

Regardless of how thoroughly you test at the unit or system level, you will not cover all of the possible ways your customers will use your software. Even if your customers help define acceptance tests, it doesn't mean that tests that pass indicate a lack of defects in your program. When acceptance tests pass, it does mean that you have created software that meets the expectations your customers were able to specify. Once customers begin to work with software, they will find ways of using it that neither you nor they ever thought about.

Here is a simple example to explain what we mean. Throughout the Construction phase, Russell and Gary used PSP Tools. Some of Russell's team used the product as well. Gary recorded his personal statistics using PSP Tools as soon as the database was implemented. Soon after we entered the Transition phase, a couple of significant defects were reported , saying that the program just hung in certain, repeatable cases. One of these occurred if you deleted a task while you were timing an activity for the same task. Even if you cancelled out of the activity timer, the program hung and you had to kill the process. Luckily, the database didn't get corrupted, but Russell and Gary decided that the behavior was unacceptable and needed to be fixed.

The defect just described is an example of one that might easily occur in real usage. But what is the chance that the exact sequence of actions that uncovered the defect would occur in the specifications, regardless of how you defined the specifications, use cases, and acceptance tests?