Design Reviews: Goals

Whether or not you read the first post in the series, this post starts the practical part of the series. How do we make design reviews less painful? How do we get engineers to WANT design reviews? Obviously, this entire series is trying to answer these questions, but the goals of the review cascade throughout the process.

I won't try to tell you that there are particular goals. Different organizations behave differently and will want different things out of the reviews. At the same time, I think there are common patterns that are unhealthy for software organizations^[1].

Goals we can agree on

Let's start off easy with the goals that I believe most people will agree on. I want to emphasize the importance of these core agreements. When we move on to more contentious goals, we should look at how these fundamental goals are affected.

Forcing more introspection on the design

I've often heard the sentiment that preparing for a design review can be the most useful part of the process. I'm not completely sure I agree with that. Even so, presenting your ideas to others has a way of forcing you to arrange your thoughts in a logical manner. If the design doesn't fit into a logical presentation framework, maybe you just found a flaw.

Attention and support from senior engineers

The easiest goal of all is the desire to get more senior engineers looking at and supporting the design. Managers love this goal. Whether the manager is worried about a junior engineer's decisions or just knows that it's good to have more visibility and perspectives, input from your staff and principal engineers can help keep a project on track^[2].

Additionally, we all benefit when designs are socialized among the teams involved. If everyone is starting from the same presentation/document/ancient runes, then we should see less difference in interpretation. Plus, socialization can help with knee-jerk, negative reactions. Combined with early reviews, most engineers will be more receptive to changes that they might be able to influence and are not imminent.

Course correct early

Every single thing I've read or been taught about design reviews states that they should happen early. Old-school waterfall development would typically review the design before any implementation.

Most places I've worked emphasize the need to review designs early to avoid implementation along the wrong path. You can save time, headaches, and dreaded midnight incidents with an early design review.

For completeness, I have to admit that almost every place I've worked has also had issues with design reviews happening too late. I'll talk more about how we can encourage earlier reviews in a later post.

Unhealthy goals

Now, let's skip to the other end of the spectrum to talk about goals that make design reviews painful or unhealthy. Since I know there will be controversy here, I'm attempting to justify my stance^[1:1].

Design sign-off

Design reviews are not for sign-offs. Period.

That was easy, moving on...

I'm kidding. I know this is a controversial take.

In my opinion, sign-offs on designs are pointless. Management often wants to make sure that all the agreed-upon goals above are met, but they phrase it as needing a sign-off from a principal review (or similar).

In practice, though, sign-offs indicate that something is ready to go. Let's say someone presents a design to you with some issues that you've asked them to go back and investigate. Are you signing off on the design? Probably not, because you think there are risks or issues in it.

Here's the thing, though: that is normal! If someone says a technical design is perfect, they are either lying or the problem is not that complex^[3].

The upshot of all this semantic baggage is a process that stresses "correctness" and "completeness" in a task that has never resulted in finalized outputs.

Especially as a junior engineer staring down a principal design review, you work hard to fill in all the gaps you can, make sure it's as air-tight as possible, and do your design review in the last month or weeks before launch.

Wait! What?

How can you course correct early (remember that goal above?) when implementation is done before the review? By talking about a "sign-off" or "approval", we've created a large barrier to getting the review as well as negated one of our actual goals^[4].

Use principal engineers to rebuild the design

Of course, everyone immediately says that they'd never state this as a goal of a design review. In reality, I've seen it too many times.

Design reviews and principal engineers are not a substitute for trusting your team. If you don't trust your team, you have a problem that has other solutions. Design reviews are not a way to have principal engineers design your system by proxy.

Poke holes in the design

I'm using this to cover a whole host of negative goals. Whether it's Amazon's "rip it apart" approach to high-level meetings or the idea that principals will be able to smugly point out all the flaws in order to tank the project, poking holes has no value.

Patching holes, on the other hand, provides tons of value. Design reviews should provide a place for finding flaws and weaknesses in the design for the express purpose of suggesting solutions. Design reviews are no interviews. They are collaborative sessions that improve the quality of the software. I'll talk more about the problems of adversarial reviews in a later post, but take my word, for now, that collaborative reviews yield the best results.

Other goals

We've covered our agreed-upon goals and the common goals that are harmful. The rest of these goals can be subjected to a lot more debate. I'm going to cover my preferred goals here along with my justification.

Spread best practices

Every software engineering group has a set of best practices. If you ask any engineer, they can probably tell you that they exist but won't be able to name a single one^[5].

Assuming that the senior engineers have some sort of community (not a given, but you really do need one), they can remind and nudge teams in the right direction during design reviews, code reviews, and in casual conversation. Besides, practical instruction in a best practice sticks in people's brains more than reading a bullet point on a screen.

Identify problem patterns

Again, we're going to assume that the tech leads/staff+/principal engineers have some sort of community. Seeing problem spaces repeated across reviews or issues solved multiple times can help these technical leaders understand where tooling or libraries need to focus, where new best practices can be developed, or what software or services need to be built or purchased. This is really a great way to feed backlog items into dev experience or framework teams.

Create ongoing exposure and communication

As I mentioned above, designs are rarely signed off, approved, or declared complete during design reviews. Therefore, the conversation continues even after a design review meeting concludes. This is awesome!

The presenting engineers get more exposure to the more senior engineers. Sometimes, this can create formal or informal mentorships. Other times, it's just good exposure for feedback. Either way, it has a lot of benefits.

Summing it up

We've covered a lot of ground here, and this ended up a little longer than I'd hoped. Here's how I would sum up the goals of a technical design review process:

1. Force more introspection on the design
2. Get more eyes (especially more senior eyes) on the design
3. Course correct early (so have the review early)
4. Spread best practices
5. Identify repeated problem areas or patterns
6. Create productive human connections between senior and junior engineers