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.
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.
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.
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 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.
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.
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.
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.
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.
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:
- Force more introspection on the design
- Get more eyes (especially more senior eyes) on the design
- Course correct early (so have the review early)
- Spread best practices
- Identify repeated problem areas or patterns
- Create productive human connections between senior and junior engineers
I'm going to be very specific about software here. Teams and organizations that deal with hardware or infrastructure can benefit from (and sometimes need) formality that I don't think benefits a pure software team. ↩︎ ↩︎
Though I may be biased here. ↩︎
Counterpoint: Design me a system to print "Hello, world!" to the terminal that everyone will agree on. I'll wait. ↩︎
I think sign-offs are actually a symptom of merging design and readiness (or operational) reviews together. They should be separate. Design reviews try to fix problems before they occur. Readiness and operational reviews attempt to mitigate issues that might (or have) occurred. ↩︎
Years ago, I was trying to explain to a junior engineer why writing up all the information in the wiki wasn't helpful. "But it's documented!" they cried. My reply went something like, "Yes, you documented it. No one will read it, though, until they have a problem or you tell them to. Most people don't start with the documentation. They start with whatever looks familiar enough to latch onto. When they have trouble, that's when they look for documentation or ask for help." Nothing has changed in the following years. You can tell because most people fix things in their homes by watching YouTube, not reading a manual. ↩︎