One of the major roadblocks for quality code reviews is how their complexity can quickly get overwhelming. The three major factors of this increasing complexity are well-known: the number of changes; the maturity of the codebase; the expertise of the reviewer. Of course, you also have time constraints that amplify this complexity.

If we don’t figure out techniques and workarounds for these issues, we are hindering the full benefits of code reviews.

We have made it our mission to tackle this complexity.

It is all about the process

In a recent Harvard Business Review article, David De Cremer and Garry Kasparov write about Augmented Intelligence and how the synergy between artificial intelligence and human intelligence can lead us to new levels of productivity.

Weak human + machine + better process was superior to a strong computer alone and, more remarkably, superior to a strong human + machine + inferior process.

Garry Kasparov

The key aspect for success is the process by which humans and machines collaborate. This is our philosophy for Reviewpad. So what’s this process for us?

Continuous code reviews are the way to go

We are stating this outright. We are very much continuous code review evangelists.

We believe it is the practice that best allows us to avoid the single greatest hurdle in code reviews, which is its mounting complexity. In this article, we will explain why. We will also explain what we mean, because:

Continuous can mean different things

Context switching incurs a lot of overhead. (…) In a continuous code review you don’t have this problem. Your pair is right there giving you feedback as you go. From little things like variable naming to bigger things like noticing a bug or telling you about an existing class you should use. The code is updated in real time.

Allan Stuart on Continuous Code Reviews

His solution implies two developers working on the same code at the same time. One of them actually creating original code, and the other reviewing live.

This is possibly as close to actually continuous as you can possibly get, but it’s not the only way to achieve this effect.

Not every company can assign two developers to the same job at any given time. Also, not every company has a pair like Jeff Dean and Sanjay Ghemawat. And the truth is, we are still understanding how pair or mob programming is adapting to remote environments.

Reviewpad is being designed to provide the same sort of collaborative and continuous mindset without this multiplication of effort.

The analyses it provides address the aspects where people are more error-prone. It’s a tool that augments human intelligence.

We believe in breaking things up into tiny parts. We also know that you don’t need pull requests to achieve that.

Our process: code review centric development

It is a well-known practice in software development to separate work into sprints and do daily syncs. In these daily syncs, you have a squad, which typically includes developers, designers, and a product owner. Someone puts up a board of issues from Jira (or some other project management tool) and the entire team goes over it.

This is a problem.

Miscommunication between the description of a Jira task and the description of a pull request happens all the time.

We propose an inversion of control. After a written high-level specification is shared with a developer, it is up to them to specify the intent of a particular changeset for development. The product owner must then understand what fraction of the high-level task these changes amount to, and adjust if necessary.

Why is this preferable? It significantly reduces specification overhead by product owners who do not have (or don’t have the time to acquire) a good understanding of the codebase. It also reduces artificial pressure on development by reducing the guesswork regarding the completion of a task.

Reviewing ideas will save you ages

Think of it as architecture. You’re building a castle. When do you bring in someone to check your work? When the castle’s already built may be a tad too late.

The idea that code reviews should only be about fixing mistakes is misguided. Code reviews should be about creating better, more efficient, code. If an idea is misguided, or flawed, then it hardly matters whether the code brings it to life perfectly.

Reviewers should be a part of the process from the get-go.

Code reviews are the central piece of this approach and that’s why we call it code review centric development.

How does it work?

As soon as a developer plans to change something in the codebase, the first step is to open a code review stating the intent of the changes and assigning reviewers. This signals to the rest of the team what this person is working on and how we can help them achieve success continuously.

Some of the benefits we have experienced in the past months are:

• reduced miscommunication, because we are asking early technical and non-technical questions about the approach;
• faster development, because we are regularly checking changes to see the progress;
• more shared knowledge, because of more frequent and better feedback;
• fewer integration problems, becausewe detect potential future conflicts.

Reviewpad was built to facilitate this type of development. Instead of forcing developers to look at a kanban of issues (which relate to the product owner, but not them), we use a dashboard of code reviews to easily communicate real progress and potential pain points.

The length of the review is as long as the developer wants it to be, since feedback is given on a continuous basis.

Instead of forcing developers to switch between contexts a dozen times to complete a code review, you can do reviews that are quicker, more focused, and kinder to your brain. 

Draft Pull/Merge Requests are an excellent starting point

The adoption of code review-centric development is going to take time. This is why Reviewpad seamlessly integrates with GitHub and GitLab. 

An excellent starting point  to this approach is to use WIP or draft pull requests. 

This feature allows you to create a draft of your pull request before you make any changes at all. And you can immediately assign a reviewer. Ideally, more than one.

If you do this diligently (and we recommend making at least two checkpoints in your draft PR a day), any reviewer who is available will be able to come in whenever they’re notified of changes, and provide you with more feedback. This way, you and your team can start feeling the benefits of continuous, iterative code reviews. 

Reviewpad’s integration of the code host draft pull/merge requests, alongside its sophisticated communications arsenal means that it’s possible and easy to start the review process earlier. In the brilliant idea stage.

We recommend that developers draft every pull request they do as soon as they think it up. Before they even touch the code. Again: If you clearly signal your code changes before they are even made, a reviewer will not only know what they’re looking for, they’ll be able to comment on your intention as well.

Async, yet continuous

If you take this iterative approach and take full advantage of the draft PRs, your reviewer doesn’t need to be working the code at the same time as you. They will be notified as soon as you have your idea, and they will be able to provide feedback on it much earlier.

Still, you need to help them! They will only be able to understand changes that much quicker if your intent is laid out clearly. If they know what they’re looking at, they will have an easier time spotting mistakes, or code that quite simply doesn’t do what it’s supposed to.

This back and forth between a developer and a reviewer is the perfect way to go about it. It’s async, yet continuous. We’re working on the right set of features to make this process easy and enjoyable.

If reviews are done this way, then they will effectively keep up with development. Over time, your codebase will never build up unreviewed, regardless of how mature it is. Conversations between developers and product owners will feel more natural and transparent. In the long-term, your team will have the right mechanisms to re-enforce trust and ownership – and when that happens, you have coding superpowers.

If you are interested in Reviewpad or hearing more about code review centric development talk with us!