What’s Your Code Tolerance? A Discussion of Peer Code Review

I spent Day 1 of my high school electronics course learning about Ohm’s law (I = V/R). Ohm’s law states “the current through a conductor between two points is directly proportional to the voltage across two points.” (See here.) To put this another way: it describes how voltage, that thing that can make you say ouch when you touch it, changes as it encounters resistance flowing through a circuit.

Typically, the resistance voltage encounters is intentional. It helps reduce the voltage to a point that, say a computer chip, can operate. Intentional resistance is achieved by using resistors. Work with resistors long enough and you’ll find that most come color coded. Resistors with a 5 band color code use the fifth band to indicate the tolerance of the resistor. Yes, I know, we’re finally getting to my point related to peer code review.

Let’s say we have a resistor that’s rated at 1K Ohms, the Ohm being one unit of resistance. If our resistor has a tolerance of plus or minus 1% (tolerance is represented as a percentage), you can expect that the amount of resistance the resistor will provide will be between 990 Ohms and 1010 Ohms. Ok, no need to discuss further, just hang on to that while you continue to read.

Collaborative Workflows and Tolerance in Peer Code Review

With the widespread adoption of Git and feature-rich Source Code Management (SCM) software like Stash or GitHub, it’s now easier than ever to implement peer code review into our everyday development process. Collaborative workflows like git-flow can make the process simpler. Practice it long enough, and it becomes second nature, just another step in the development lifecycle.

Hopefully, you’re reading this and thinking to yourself that your development team already practices peer code review and some form of a collaborative workflow like git-flow. If not, I would strongly encourage you to start moving in that direction. Don’t feel bad if you have yet to adopt these methodologies. We frequently encounter large corporations who have also yet to adopt. Tangent completed.

Differences in Approach

Developers typically come from different coding backgrounds and will apply their own approach to each development solution. You use a for loop in places where I typically use foreach. I know, I know, weak example but we’ll let it slide. So now I’m reviewing your code, looking at your new carefully crafted for loop. It’s an okay implementation, but I’ve seen better. I think my foreach would be more aesthetically pleasing. That little twitch in my brain is so strong that I just can’t stop myself from commenting on your Pull Request (PR). Of course, I use my fancy SCM to do so and wait for you to change the code before I approve it.

My example is a little extreme but hopefully, you see my point. My peer now needs to context shift because they probably saw the Outlook email notification pop up while they were working on another project (another feature of our fancy SCM software.) He/she calls me to discuss why their implementation of a for loop wasn’t appropriate. After giving up the debate because, well, I am right about my foreach, they change their IDE from the project they were working on and check out the feature branch for the Pull Request in question. Then they make the requested change, rebase the branch, and push the fixed Pull Request. They’ll also want to open the fancy SCM software and reply to the original comment to notify me that they fixed my twitch.

The Cost of Low Tolerance in Peer Code Review

As with resistors, my low tolerance level comes at a cost. The low tolerance level I applied in my peer-reviewing example likely just cost the project a minimum of 15 minutes. Now compound this over the course of a six-month project. Your peer review process likely just ate hundreds of hours and thousands of dollars. Again, my example may seem extreme but I would urge you to do a little research on the cost of context, or task, switching. See this reference for a good start.

I am in no way suggesting that peer code review is not important or that there are no wrong ways to code things. There are most definitely wrong ways to code things. If a Pull Request doesn’t work at all or doesn’t follow coding standards set in place by your team, you need to fix it. On the other hand, if a Pull Request is working code but simply doesn’t follow the latest and greatest design pattern or coding trend, consider upping your tolerance. Use the Pull Request as a teaching opportunity for the more junior developer, but allow the Pull Request to stand. You’ll save your project development hours while creating less frustrated and more knowledgeable peers.

Building a Tolerance in Peer Code Review

At Soliant Consulting, we liken our development process to that of building a home. We start with our Foundation phase of blueprinting. We then build a foundation for the application and then frame out the application into separate modules. We then finish the build according to the blueprints.

During the course of typical home construction, there will be hundreds or even thousands of cuts made, some by an experienced craftsman and some by the high school graduate. The experienced craftsman knows that when cutting a board to length, one should account for the width of the saw blade making the cut. The high school graduate does not and cuts to the inside of the mark, making the board an eighth of an inch too short.

Now the experienced craftsman must make a tolerance decision. He can use the short board; after all it still fits and will pass inspection. Or, scrap the board, reiterate how to make a proper cut, and encourage the high school graduate to try again. Each scenario gets the house completed according to building codes and will more than likely not have an effect on the longevity of the home. However, the second will produce project waste and a loss of time.

The review of the graduate’s cut is a necessity; there is no scenario where the process of peer reviewing can be removed. The underlying issue here is what to do when code falls short of expectations. Having the graduate redo the cut or use the short board are both potentially viable outcomes.

Implementation of tolerance as it pertains to peer code review is a balancing act. Recognizing this will help your team foster a culture of tolerance and improve the performance of your peer review process.