Divergence of Code and Design over Time

As Figure 7-1 shows, some divergence between the design and the code is normal and should be expected, and the “idealized” case of 100% conformance between the design and the code will rarely be achieved. “Traditional” ICONIX Process uses the Critical Design Review (CDR) to make sure the design is specified at an appropriate level of detail that the code headers can be generated from the classes. With a low-ceremony approach, the CDR might get skipped, or at least not be as rigorous. By introducing code reviews at the end of each release in Agile ICONIX, we have another opportunity to bring the design and the code back into sync. If refactoring is used to “clean up” the code, this refactoring should be reflected in the sequence and class models so that these models can continue to be useful during the successive releases. The code review is really a code and design review.

Figure 7-1: Combating the gap between code and design

As the software evolves over multiple releases, we’d hope to see the gap between the design and the as-built code growing progressively smaller. If the gap between the design and the code is large in one iteration, this should be an indicator to pay closer attention to CDR during the next release.

The gap between the design as specified on sequence and class diagrams and as-built code can be minimized by aggressively driving the code from the design (allocating operations to classes from sequence diagrams and generating code headers from the modeling tool), and by aggressively reviewing the detailed design (via CDR; see Chapter 3 for more details). If the as-built code diverges from the design, it can be brought back into sync after each release during a code review.