Resistance to Schematic and Layout Review


The team lead or line manager enters the room and calls a department meeting or a design review session. Suddenly, almost everyone on the team starts mumbling or reacting with groans.

You’ve probably all experienced this situation. As a hardware guy, you have little tolerance for interruption, especially for long and tedious meetings that impede your productivity. The idea of having to sit and listen to other people discussing a blurry projected schematic, or working through a printed PDF booklet just so that your design-challenged colleague at the other end of the room can find out what he’s doing wrong, can be really upsetting.

The concept of design review has been around for a long time. Everyone knows the value of double-, even triple-checking your work (think back to elementary school). Every discipline has worked out a formal or informal collaborative process for checking and validating work: Writers have editors, accountants have auditors, and software engineers came up with pair programming a decade ago.

Software’s got it right.

There used to be a time when the conceptual design phase for software development lasted much longer than it does today. But it eventually became widely recognized that the static, non-iterative model of development (school teachers call it the waterfall model) was not effective in producing quality products on a competitive schedule.

So software development evolved to what it is today: agile and iterative. Its rapidly-changing nature creates continuous opportunities where peer code review is valuable and necessary for quality results.

In the same light, regular peer schematic and layout reviews should be seen as a logical component in the hardware development process. Some direct benefits to incremental design review include:

  • Fewer defects and errors in final design
  • More errors caught early on when they’re cheaper to fix
  • Improved communication and knowledge about design content (bus factor)
  • Mentorship of junior members of the team

And some longer-term, indirect benefits:

  • Lower number of revisions & re-spins
  • Faster time-to-market
  • Less time spent on debugging

Egos, isolationists and crappy toolsets.

Reading those lists of benefits, it should be a no-brainer to implement design review into the development cycle of every project. And yet, many hardware companies still don’t have peer review as a regular and mandatory part of their design process. Why? There are two very straightforward answers when you dig into the basics of human psychology.

  1. Ego
  2. Outdated reviewing methods

Let’s start with ego. We’re talking about hardware engineers right now but this applies to a vast majority of people at their workplace. We naturally feel like our work is an extension of ourselves. Someone judging our work is like having them judging us.. Two different types of people/engineers emerge at this point: The first class consists of collaborators, team players, and those who see it as constructive. When confronted with a problem they can’t solve, they will naturally turn towards a peer who knows the answer. For these guys, peer review is a beneficial process.

The second class is made up of isolationists. When confronted with a problem they can’t solve, they would rather unproductively try to find a workaround for hours (even days) rather than reach out to their peers for help. These guys can’t admit that someone else may know something they don’t.

Attitude over aptitude

In 2002, it was reported that the average career in high-tech lasts around 8 years. The isolationists are doomed for a shorter one, as their body of knowledge exclusively lies in what they are able to figure out on their own.

Overinflated egos can’t be good team players because their faculty to share with and learn from others is impaired. On the other hand, collaborators showing a continuous interest in learning will increase and sharpen their skills, remaining productive (and employable) in a constantly-changing field.

Design review can be painless.

Reviewing hardware designs has not been commonly included in the standard development cycle in a majority of companies for another reason: The tools are not adapted. PDFs, projectors, meeting rooms and highlighters are completely outdated ways of reviewing design. Back-and-forth email threads and over-the-shoulder methods are also inefficient and a waste of time. The key is to introduce a technique which allow each member to contribute to a review when they’re focused and willing to do it. It also shouldn’t include an archaic, middle-step that slows down the execution of fixes.

If you’re thinking about implementing an efficient design review process within your team, let us know. We’re happy to help. There’s no longer an excuse to not review designs!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s