What should design reviews accomplish?

Wednesday, September 7th, 2011 by Robert Cravotta

I remember my first design review. Well, not exactly the review itself, but I remember the lessons I learned while doing it because it significantly shifted my view of what a design review is supposed to accomplish. I was tasked with reviewing a project and providing comments about the design. It was the nature of my mentor’s response to my comments that started to shape my understanding that there can be disconnects with idealism and practicality.

In this review, I was able to develop a pretty detailed understanding of how the design was structured and how it would work. The idealist in me compelled me to identify not only potential problems in the design but to suggest better ways of implementing portions of the design. My mentor’s response to my suggestions caught me completely by surprise – he did not want to hear the suggestions. According to him, the purpose of the review was to determine whether the design did or did not meet the system requirements. The time for optimizing design decisions was passed – would the design accomplish the requirements or not.

His response baffled and irked me. Wasn’t a design review part of the process of creating the best design possible? Also, I had some really blindingly brilliant observations and suggestions that were now going to go to waste. Looking back, I think the hardline approach my mentor took helped make me a better reviewer and designer.

As it turns out, my suggestions were not discarded without a look; however, the design review is not the best point in the design cycle to explore the subtle nuances of one design approach versus another. Those types of discussions should have occurred and been completed before the design review process even started. On the other hand, for areas where the design does not or might not meet the system requirements, it is imperative that a discussion be initiated to identify where and why there might be some risks in the current design approach. My mentor’s harsh approach clarified the value of focusing observations and suggestions to those parts of the design that will yield the highest return for the effort spent doing the review.

Does this sound like how your design reviews proceed or do they take a different direction? What should be the primary accomplishment of a successful design review and what are those secondary accomplishments that may find their way into the engineering efforts that follow the review process?

Tags: ,

9 Responses to “What should design reviews accomplish?”

  1. R.S. @ LI says:

    Too often the ‘design review’ happens at the end, when the discussion is mostly pointless. At that point it can be a boring affair where the presenter has wasted at least a day of his time putting together the presentation, and then proceeds to waste an entire room of peers time.

    These discussions should happen at the beginning of the process, after the rough design sketch so that there’s less emotional investment (meaning more amenable to change and open to suggestions) and less time wasted if there does need to be a direction change.

  2. A.M. @ LI says:

    As per r., too often it happens to late and ends up being a review battle meeting rather than an opportunity for peers to share experience and wisdom on how to tackle design issues.

    As per the Mentor the review need not present solutions only identify weaknesses

  3. M.K. @ LI says:

    My experience is that most participants are clear on the mission: to find problems not to criticize or to offer suggestions. When it does happen others are fairly quick to get the discussion back on track. My biggest issue is that they are usually scheduled at the last minute with no time to prepare.

  4. B.N. @ LI says:

    In the place where I work the design review takes place in the next meeting following the requirements one. The review is done by peers within the team so no room for supervisory or authoritarian reviews. Everyone gives his 2 cents in the design until we have a bigger and clearer picture of the way our software project will behave and what is needed to be done by individuals to accomplish the task. It is more of a planning the work needed and how we’ll do it. Everyone learns from everyone and the outcome always much better than a sole opinion.

  5. E.M. @ LI says:

    There can be many different objectives of a design review. I believe the objective of the design review as mentioned in the story that started this thread, was to see if the design met the requirements. If so, then the analysis that goes into the design review results is the design meets requirements criteria.

    If the purpose of the design review is to have a group review design architecture, then the outcome will be the decisions made by the group. (Windows vs Unix, ARM vs Intel etc)

  6. B.C. @ LI says:

    To keep me emtionally free during design reviews, I keep a mantra close at heart. All designs are valid, some are more efficient than others, and all have compromises. Do the compromises meet the requirements.

  7. G.L. @ LI says:

    The straightforward answer is simple: the purpose of a
    design review is to identify flaws in a design before the
    team spends untold hours trying to track them down by

    Note that I worded that so it does not matter whether you
    are reviewing hardware or software or a mixture of both.

    In fact, I cannot tell from your question whether you meant
    one or the other, or left it intentionally open.

    I have worked in various organizations that interpret that
    word very differently.
    - At one place the software design review took place before
    the coding stage, at a time when the developer was most
    open to ‘suggestions’ and ‘improvements.’
    - Next week, I will be presenting an overview of a task I
    have nearly completed. I would, like your mentor, be very
    reluctant to scrap everything I have done on the
    pronouncement of some whippersnapper that his way is
    ‘cleaner’ or ‘brilliant.’
    - I have worked at one place where the term ‘design review’
    meant only checking that all the ISO-mandated production
    documentation was in place, and had nothing to do with the
    design at all!

    It might help the discussion for everyone responding to this
    post to declare his/her definition up front.

  8. R.S. @ LI says:

    My humble comment also falls in the category “define a term prior to using it”:

    And: Definitions should talk about facts, not “feelings” and “moods” about the “flavor” of a subject. Just tell things that counts, things something boils down to.

    A “passed review” I would define as the point in time where a company or a project leader overtakes the responsibility for the results from a producer or a producing team.

    “Design” I would dived into “Architectural Design” which is a group approach and “Detailed Design” which is an individual approach. However, these terms need clear separation: When do the responsibility of an individual designer start and what they are allowed to criticize to change with respect to architectural design?

    Still, I like to get pointed to a definition of Design, architectural or detailed.

    After that, the question of “what hinders a design review to pass” should be not as tough to answer.

  9. T.E. @ LI says:

    As the number of applications based on systems with high complexity grow, it’s less a question of automation addiction than a question of understanding complex systems (and their potential failures).

Leave a Reply