Happy Friday,

I hope you had a great holiday weekend for those of you in the US. I've been very busy with the end of my children's school year and my beekeeping season starting up.

Did I tell you I caught a swarm of bees? I have three hives this year!

I didn't have all the equipment for a third hive, so I've been scrambling to buy and assemble the extra hive boxes and frames I need suddenly.

I've also been pretty heavily engaged in an online community for technical leaders who wanted to have a focused conversation on topics like continuous merging, which led to a conversation about pull requests and code-reviews.

Many folks shared their take on making them easier with tools, tags, and automation, but I shared my simple take—eliminate them.

I'm fortunate in that I've seen many company and team approaches to pull requests, and I've tested many variations with them. This is one of those practices that people accept as necessary, but it truly isn't.

Pull requests and code reviews are a mechanism for inspection. Sort of like if you were building a car in a factory and inspecting it at the end of the assembly line. The single biggest problem with this approach is that you're trying to find the problems that were created earlier.

That car with bad brakes was defective twenty steps ago.

It would be better not to create the problem in the first place, but I'll return to that.

While this is a simple analogy, our industry's approach to PRs and code reviews is largely lazy and ineffective. First, almost no team has any standard or checklist they reference. Each code review is based on personal experience. This produces wildly inconsistent results. Further, the handoff from the developer to the reviewer is often absent of context, which means the likelihood the reviewer provides relevant feedback is in jeopardy. Finally, the reviewer is never dedicated to reviews and has to interrupt their work to do a review. This typically leads to reviews taking days to accomplish.

The silent killer, though, is that many reviews are cruel and demoralize teams.

And for all of those issues, the benefit is you might catch an issue before the code is promoted. If you're a fairly mature organization, the issue would be in design. If you're a less mature organization, it'll be an actual defect.

So the question is, can you get the benefit of better design or quality without waiting for days and all of those other poor aspects of a review?

Yes!

The approach is simple. Developers work together throughout development. Design gets constant feedback throughout, as does the approach to quality and testing. The code that gets completed already has the best two developers can manage.

Some of you might think this is inefficient because now we have at least two developers looking at one thing.

What I've been able to show repeatedly is that when I eliminate the PR/review process at my clients, they often see a gain of speed from 3-10x. The quality is also higher than before, and the team is a lot happier after they acclimate.

When it comes to topics like reviews and pull requests, I find a lot of people are wholly unscientific about how they approach these processes and their measures of effectiveness. They're accepted as the way things are because they like them, so teams and companies invest countless resources to stay in that rut instead of being analytical and experimenting with alternatives.

So what do you think? Got frustration about reviews and pull requests? Think I'm nuts? Reply and let me know!

Sincerely,

Ryan Latta