Development Reviews Are A Hassle But Worth Adopting

2022-09-05 original Engineering

Let’s start by considering why development reviews don’t get adopted.

They’re a hassle, including schedule coordination
There’s no suitable person to act as reviewer
The development team is very small

Conducting development reviews is a given. Of these three, only one is a legitimate reason not to: team size. When a team is extremely small, detailed design information and status may already be shared between members without any need for a formal review session. This is especially true in software development where a system like git is used properly, or in hardware development where the person drawing the schematic and the person placing orders are different people. In these cases, daily work has already become the review, which is a very convenient situation. In my experience, this kind of close coordination arises naturally as long as the team’s total headcount stays at 6 or below.

Once a development team passes a certain size, though, this stops working. The only time people at opposite ends of the team see what each other is doing is the weekly regular meeting. Task management sheets and progress status get shared through a system, but nobody actually looks at them. When such a team finally holds a review meeting, it often turns out that “this is the first time we’ve seen each other’s schematics.” Comments from someone seeing something for the first time often hit the essence of the matter. If team members throw naive questions at each other, the review meeting is bound to be productive.

Let’s turn to the challenges. Schedule coordination is a very troublesome issue, and it’s often the reason reviews end up as mere formality. The person responsible for a given department can’t make it every time and keeps missing meetings, or the meeting keeps getting rescheduled until months pass and even the fact that it was rescheduled gets forgotten. This is an organizational problem, so each organization has to solve it in its own way, but let me offer a few ideas.

For example, something like “9:30-10:00 on the second Wednesday of every month.” A time slot when no regular meeting is normally scheduled works best. When there’s nothing that needs review, that slot gets released. Since it’s a fixed slot on the schedule, squeezing in another meeting there is forbidden. This is an effective method for organizations with a reasonably large number of products or projects.

This connects to point 2 as well. The reviewer needs a certain amount of experience, not just to make accurate observations, but to look at things with a constantly suspicious eye, informed by the patterns behind certain kinds of mistakes. People suited to this are surprisingly limited in number. By designating that person in advance and reserving only their schedule properly, you can reduce the effort of schedule coordination. At large companies, a veteran engineer often fills this role, and depending on the situation, it can also be a good idea to look for suitable talent externally, such as freelancers.

Of course, it’s also conceivable to solve this through some kind of punitive system for enforcing review execution: “the manager strictly manages it,” or “build a system that makes shipping impossible without a review.” That approach would carry stronger enforcement power and would likely take effect faster. But it seems ill-suited to companies of medium size or smaller, since it places too heavy a burden on them. Finding an operating method that is as unforced as possible is a key point when introducing any new process into an organization, not just development reviews.

The content of this post is an excerpt (original text) from the following book. If you’re interested, please get a copy of the book.

The Shape of a Happy IoT Startup

Originally published in Japanese at https://clazytech.com/2022/09/1149/. Translated with LLM assistance and reviewed before publication.