I think design reviews are even more valuable than code reviews. They happen earlier in the design process, and defects caught earlier are less expensive to remove. The subject of the reviews is more interesting and less tedious, so people want to come. We would review a .h file containing a single large and well-commented class definition, ypically 100-200 lines, in an hour. Presented alongside the .h file was a CRC Card, a lightweight text document of 1-3 pages. Rebecca Wirfs-Brock has written two books about CRC Cards, which I also really like for their bervity and informality. Sometimes we would review the skeleton of the .cpp file too if the presenter thought that would be interesting. By the time we had done half a dozen design reviews, we realized there was a standard list of questions that were always going to be asked unless the design explicitly accounted for them. We wrote these questions down and made the document available to the whole team, so that each team member would pre-review their class against the questions. This greatly streamlined the review process. As lead, I arranged for the first couple of reviews to be on my code, because (1) I thought I could bear up under the scrutiny without becomming defensive, and (2) I was an experienced developer, so I thought my code would be a shining beacon of reason and elegance. To my slight chagrin, the reviewers, inexperienced though they were, were capable of finding defects even in my beautiful interfaces. I learned a lot about my own practice. This turned out to be fortunate. We were able to establish that nobody was so good that they didn't need reviewing. We also established a polite and professional team demeanor for pointing out issues in other peoples' code. I was careful to point out during the first couple of reviews that we would all have a turn in the hot seat, and payback was a bitch, so that politeness and selflessness were good attitudes to practice. We also had architectural design meetings. These would be familiar to any dev who has been in on a project during design. We drew interaction diagrams and class diagrams. We had an electronic whiteboard that copied onto fax paper. I highly recommend some such aid. The technique we did that was most helpful was structured walkthroughs, in which we would try to follow a thread of execution through each objec and method call. The technique is valuable during design, precisely because you have to say, "main() constructs the foo object and then calls foo::init() to initialize it. foo
