Comments on: What should design reviews accomplish?

By: T.E. @ LI

T.E. @ LI — Mon, 12 Sep 2011 14:08:51 +0000

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).

By: R.S. @ LI

R.S. @ LI — Mon, 12 Sep 2011 14:08:33 +0000

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.

By: G.L. @ LI

G.L. @ LI — Sat, 10 Sep 2011 19:15:55 +0000

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
testing.

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.

By: B.C. @ LI

B.C. @ LI — Fri, 09 Sep 2011 21:31:17 +0000

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.

By: E.M. @ LI

E.M. @ LI — Fri, 09 Sep 2011 21:30:57 +0000

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)

By: B.N. @ LI

B.N. @ LI — Fri, 09 Sep 2011 21:30:29 +0000

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.

By: M.K. @ LI

M.K. @ LI — Thu, 08 Sep 2011 16:32:37 +0000

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.

By: A.M. @ LI

A.M. @ LI — Thu, 08 Sep 2011 16:30:41 +0000

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

By: R.S. @ LI

R.S. @ LI — Thu, 08 Sep 2011 16:30:19 +0000

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.