Like a 10 year old heading to the dentist, the design review stage of a project is one of those areas that will drive a series of heebie-jeebies in even the most iron stomached software engineer or designer.  You’ve spent time with your users and business analysts.  You’ve diagramed all of the ins and outs of your solution.  Now you have to present your design to others and convince them why your design is the best approach to solving the problem within the constraints of your project.  Let the stomach aches begin!

When considering your upcoming design review, there are a few questions that you need to ask yourself.

1. What is the target audience for this review?
2. Has the audience spent the needed time reviewing your documentation?
3. Are you prepared with answers to those reviewers that want to provide alternatives?

What is the target audience for this review?

For a successful design review you must understand your audience.  A strong designer will understand the technical level, responsibilities, and motivations in their design audience.  For example, if you are presenting your design to other senior technical leads within your immediate organization, you will want to structure your presentation to a level of technical review that is much deeper than if you are presenting to a group of architects.  Each type of audience will bring its own challenges.

Keep in mind that there is no design that at least one person can’t review and claim the opportunity for improvement.  Suggestions for change to your designs are occasionally motivated by technical philosophy instead of the merits of the design itself.  A well prepared presenter will use their understanding of the audience to work through these conditions.  As a rough example, sometimes a reviewer will believe that object oriented design is the answer to all solutions no matter the complexity of indirection and/or misdirection that object oriented design offers.  That person will likely challenge your designs on your use of data encapsulation, inheritances, and state if they are not all encompassing.  The more you are prepared to justify your design decisions for this review meeting in those low-level technical areas – they better you will be able to respond.  Just remember that a design review is not about finding a “different design” but to find the “best design” that meets the goals of your project.

Has the audience spent the needed time reviewing your documentation?

The single most time draining failure in a design review is if your audience has not reviewed your documentation before the meeting.  No one usually wants to sit in a two hour meeting listening to you read through your design document line-by-line.  Heck, I don’t even like having to read through my designs line-by-line.  To ensure your audience is prepared for your reviews, make the effort to give each participant the time to complete the review.  I also like to elicit a response from each participant before my design meetings where they are asked to confirm that they have read the design and are coming to the meeting to ask questions about the design itself.

At the beginning of the presentation, inform the participants again that the review meeting is an opportunity for them to ask questions about the design’s approach to solving the problem.   Good meeting management by the presenter is critical in preventing the meeting from turning into a document read-along.   If your project schedule and company culture allows, stopping the review for rescheduling if it becomes obvious that the review was not done by the majority of participants is sometimes a good peer-pressure trick to ensure the participants understand their role in the effort.

Are you prepared with answers to those reviewers that want to provide alternatives?

“Defence is our best attack” Jay Weatherill

The most effective tool a designer has in their arsenal is that of alternative solution investigation.  The designer must spend the time needed to explore the alternatives that may come out of a design review before the review occurs.  As quick on their feet as many designers believe that they are in answering a technical challenge with partially correct answers, I’ve seen situations where the reviewers that actually do know the correct answer to the technical challenge begin to doubt the designer’s credibility.  If you don’t know the answer to the feasibility of an alternative solution – just say so and take it off as a follow-up action.

Remember that the design review is not about you.  The review is about the proposed solution – not the person presenting it.  Assume your reviewers are looking for the best solution for the problem – not attacking your ability to design it.  In the end – if your design is well thought out and you’ve considered all of the possible fallacies of the approach – your design will only be improved by the combination of minds reviewing it but will usually enjoy more support from those that accepted the design.

I’ll provide a personal example to this topic.  I had worked on an application for two years of design, development, and maintenance.  The application had been reviewed over and over by at least 15 difference architects, senior developers, and designers over that period of time.  A new person joined the group and in about 45 minutes of reviewing the design suggested a hole in our solution that had been leaking memory for the entire two years.  We had been lucky enough to have loaded maintenance releases often enough to not have seen it – but sure as heck – it was there.  It never ceases to amaze me how just a single person can sometimes find something that the larger group never recognized.

In summary, embrace these design reviews.  Conducting a series of reviews taken in a positive manner and demonstrating solid understandings of risk analysis and thoughtfulness has propelled many developers into high-level roles and responsibilities.  Look at each design review as an opportunity for you to learn something new.  I assert that if you do – not only will you gain personally through your learning – but the designs you produce will be more solid and less prone to failure…and everyone like to support that kind of software.