Design Reviews Part 1: Why does everyone avoid them?

Welcome to the first entry in my series on technical design reviews. How, when, and why design reviews happen has always been contentious. Without dealing with the conflicts between the various motivations, we cannot pave our way to a more productive and less disruptive process.

What do design reviews look like?

Obviously, I can't tell you what all design reviews look like. Different companies (and sometimes different teams within those companies) have different formats for reviewing technical designs.

I'll cover three types of review that I've experienced. Afterward, we can work through why they discourage rather than encourage.

Semi-formal Team Review

Let's start easy with a team design review. Reviews within a team tend to be less formal, but that doesn't make them easier or more pleasant. Typically, these reviews include some minimal presentation of the design and a lot of time for discussions and questions.

I've know a lot of teams that thought they worked well together and got along until they had a design review. For some reason, these meetings tend to bring out aggressive and unpleasant behaviors in some people. Let's be honest, though. Team reviews are typically dominated by the tech lead (whether that's a formal position or not). Being grilled by your tech lead can be daunting. Trying to provide feedback to your tech lead can be just as hard.

In practice, even if you can get more equal participation, some topic is going to derail the conversation. The presenter will feel the need to defend the design. The entire meeting will spiral out of control. Everyone will leave exhausted and uncertain about what, if anything, needs to be done. God forbid there needs to be another meeting.

Design Review Board

The next format in the list is the Design Review Board or DRB. DRBs were the mechanism of choice at Salesforce when I was there. DRBs were typically standing meetings (usually every 1-2 weeks) where each session had a presenter. No presenter? No meeting! (Yay!)

Since the DRB happened every week, the invite list didn't really change. The same people were always invited (plus the presenter). In practice, this usually meant that a presenter had 10-15 architects and principal engineers asking them questions and derailing the conversation.

Ultimately, DRBs end up much like the team reviews. There's a lot of churn, a lot of work to prepare, and usually very little useful feedback.

Dedicated Reviews

For lack of a better term, we'll call this last group "dedicated reviews." In Amazon parlance, these are principal reviews^[1]. Typically, these meetings last for a couple hours, involve up to 3 reviewing leads/principals/architects, and get very detailed.
Of the 3 types I'm listing here, I've found the most benefit from this one. That said, it's not without problems. The biggest problem being that amount of work expected before the meeting.
For many of the more junior engineers, this could be their first encounter with a principal or architect. Let's face it, we're not usually known for our warm and sympathetic demeanor^[2]. True to form, the presenting engineers either do a lot of work ahead of time, or they risk the wrath of angry, moody principal engineers.
I hope the problems have become obvious. Too much pre-work means the review is probably happening too late^[3]. If the presenter is terrified, is this really helping anyone? What are we even doing here?

Where we go from here

We've got some serious problems here. We have several formats that seem to frustrate and district more than help teams build high-quality, scalable software.

Over the next several weeks (not necessarily consecutive), I'll have posts to dig into a better way to do design reviews. So far, the outline looks like this:

1. Goals
2. Attendees
3. Format
4. Patterns and Anti-patterns
5. Making it all work

I hope you will subscribe or check back.