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 of patterns. I have seen them lead to great advances in software architecture. I have also seen a retrospective as a natural tool to use in discovering the great refactoring opportunities available to a team.

Through a retrospective, I've seen a community of minds understand the current structure of a system and collectively consider refactoring opportunities from a variety of viewpoints. The result is not just a better architecture, but also a group understanding of why the system is changing. Thus maintenance can be performed by a wider group of people; defects disappear; group ownership increases ; and everyone involved becomes better programmers. Naturally the lessons learned from refactoring stay with the developers as they move on to other projects, thus the professionalism of software architecture and design continues to grow.

PERFORM A RETROSPECTIVE AFTER EACH RELEASE

Examining your design and how you created it can help in the next release .

The more often you can perform a retrospective, the sooner you can use its feedback. You could hold a brief retrospective after every internal release and a longer retrospective after every major release.