Design Reviews - Best Practices

Yes, you're reading it correctly. I'm back! I've been very busy lately, but I have finally found the time to submit this blog entry I had lying in the drawer for quite a while. Enough!...let's get on-topic:

Best Practices For Conducting Design Reviews

A lot of people would agree that design reviews can bring a lot of value to building quality software. However, when it comes to actually doing a design review we enter a somewhat blurry environment where everybody has another view on what a design is, how in-depth it should be etc, how it should be organised, etc.
Based on my own experience, I want to share the following tips and best practices with you :

1) Provide some overview material to the audience up-front. I want to stress the word 'overview material'; don't scare them off with implementation details.

2) Design reviews ask some discipline of the reviewers and in most cases a moderator comes in quite handy to make sure that you stay 'on target'. Although the 'official' character of the design review should not be exaggerated, it shouldn't become a coffee-chat neither.

3) Make it clear to everybody to 'be prepared'. People that didn't do their homework should not be attending or - at the very minimum - don't really have the right to speak. A moderator should be assigned to tackle such occurrences.

4) Requirements should be questioned during a review session of the requirements, not during a design review. Of course, for a good understanding the requirements should be explained properly (with a bit of background when required) prior to starting to talk about the solution. Mixing a discussion of the requirements and design is the best recipe for a long discussion without any added value.

5) A by-product of a design review is documentation. Independent of how 'agile' your team might be, it always comes in handy to have some form of documentation which can be used in the future to get an overview of what problem a certain design is solving and what te main concepts of the solution are.

6) Make sure that to stay at the right level of abstraction. The moderator should block implementation-detail discussions; instead he/she can take note of an action point to check what technology X or component Y could bring to the solution of the problem.

Finally, you should be aware of the danger of design reviews. One of the dangers is that the person responsible for the design starts making the design more complicated than it should be because he/she sees it as a way to demonstrate his/her technical capabilities to the audience. To migitate this risk, you should clearly communicate that complexity is only appreciated in case that there is no simple solution. Make sure that the addendees are also aware of this. In an environment where technical complexity is praised, nobody will even think of proposing a simple solution to a problem.

About the author

Mario Van Damme is a software architect, working for quite a number of years in the medical industry, and prior to that in the insurance and banking industry.
He can be contacted by e-mail at: mvandamme~AT~sopragroup.com and mario.vandamme.mv~AT~belgacom.net.