Prefactoring

8.2. Retrospective Time

Now that Tim and I have finished our first version of the system, it is time to perform a retrospective . A retrospective is a form of feedback. In a retrospective (Project Retrospectives: A Handbook for Team Reviews by Norman L. Kerth [Dorset House, 2001]), the team members analyze the team's personal interactions. They can also examine the design and architecture.

You can review your project journal and see where design decisions were made that had to be altered later. You might consider why a decision was made the initial way: speed, misunderstanding, or lack of information. You can try to modify the way decisions are made in the next iteration to decrease the amount of alteration required.

As occurs often in development projects, you might have to cut corners on your principles to create a working system quickly. At retrospective time, acknowledge those corners that you cut and determine whether they are severe enough to warrant refactoring. Cutting too many corners creates an illusion of greater velocity toward meeting the goal. It is like not eating so that you have more time to code. Eventually the lack of eating will catch up with you. I cannot overemphasize the power of retrospectives. Norm Kerth writes:

The ritual of retrospectives gives vast insight into the actual technical decisions and discoveries made. I'm a strong advocate of patterns, and especially pattern languages. A retrospective is a great way to identify valuable patterns and systems ...