People take for granted that code review hasn’t always been common practice. Once upon a time, engineers coded. Some coded together. Some printed out the code and inspected it together in the same room for hours. Some eventually started working on coding projects remotely over email. They’d send patches to one another and comment on the patches in the email threads (insanely freaking slow).
As soon as the 2000s hit and code review went digital, advancements happened quickly. Google used Perforce to manage changes and in 2006 built Mondrian to facilitate peer review. Linus invented Git to track Linux changes. GitHub was invented and incorporated email patch threads in the form of “pull requests.” Facebook replaced Git with Mercurial in 2013, and built Phabricator to manage “diffs.” Google replaced Perforce with “Piper” internally around 2015.
As software engineers, we all know the importance of code review in improving code quality and catching bugs before they become bigger issues. But have you ever wondered about the origins of code review and how it became the ubiquitous practice it is today?
Note
Greg spends full workdays writing weekly deep dives on engineering practices and dev-tools. This is made possible because these articles help get the word out about Graphite. If you like this post, try Graphite today, and start shipping 30% faster!
Where it all started
Believe it or not, the idea of code review dates back to the 1970s. In 1976, an IBM engineer named Michael Fagan published a paper called "Design and Code Inspections to Reduce Errors in Program Development." This paper introduced the concept of "Fagan Inspections," which were considered good practice but extremely burdensome.
The practice described in the paper became popular enough that later IBM engineers would refer to reviews as “Fagan Inspections.” A “reader” would be chosen by the coder and would be expected to “paraphrase the design” of the code. Once the design was understood, “the objective [is] to find errors.” Questions were allowed only “to the point at which an error [is] recognized” and no further. Each error would be categorized by severity. Obvious solutions were allowed to be noted, but the inspection was not a place for discussion of alternative designs - “it is intended just to find errors!”
It wasn't until the 90s that peer reviews evolved into desk checks - a method where the author of a document or piece of work self-reviews their work before submitting it to others for review. Even then, desk checks were only performed by a minority of developers.
Code review goes digital
Fast forward to the early 2000s, and we see the birth of online code reviews. As computer technology became more prevalent, desk checks began to evolve into an electronic form of peer review. Thanks to advances in source control systems like Git, it became possible for developers to collaborate on the same code base from anywhere in the world. This led to the creation of the earliest version of web-based code review by Guido van Rossum at Google, which eventually became known as Mondrian.
Mondrian was a closed-source, web-based code review tool that was ahead of its time. It focused on two key pages: an inbox of code changes that either you created or that you needed to review, and a per-code-change page that allowed you to title and describe your change, leave inline comments, and even show what changed since you last reviewed. The interface was inspired by Gmail and kept the actionable code review front and center.
Slides from Google Tech Talks: Mondrian Code Review on the Web in 2006
Modern-day code review
Fast forward a bit more, and we arrive at GitHub. While GitHub is undoubtedly the most popular approach to code review today, it differs from Mondrian's original experience in a few key ways. GitHub puts the repo rather than the individual experience first, showing you the repo as a whole instead of an inbox of individualistic information. Pull Requests (PRs) on GitHub show you a forum of conversation and push code reviews to a second page, whereas Mondrian kept the actionable code review front and center. Why? GitHub was trying to solve the problem of open-source maintenance and collaboration, while Mondrian was trying to solve code review for a closed-source company.
So, what's the future of code review? We'll likely live in a world with both systems: one optimized for the problems of open source, with slow changes, large debases, and admin roles, and another focused on closed-source, with a fast review culture, small changes shipped frequently, and smaller teams with fewer flame wars.
Code review has come a long way since its inception in the 1970s. It's incredible to see how much it has evolved and how it has become a standard practice in modern software engineering.
