Ben Hansen

Developer for Morley Group

Ben Hansen

Developer for Morley Group

Keeping Each Other In Line7 min read

In school, did you ever have to write a paper that was to be peer reviewed?  Possibly, this task made you alter the way you would normally write.  It might have forced you to take your audience into consideration.  Also, maybe you paid more attention to your spelling and punctuation to avoid embarrassment.  Many (not all) would have avoided controversial topics in order to not stir anyone up.  As a software development team, we peer review each other’s work at set intervals (not as scary as it sounds). Your high school teachers didn’t have you do this just because they’re lazy graders. The 3 effects below are pretty helpful when writing software.

First, altering how you write to please your peers is important when writing software.  If code is unreadable by anyone but you, then it can be difficult to integrate, remove bugs (pesky software errors), and be difficult to reuse.  It’s nice if your end of the project can work by itself when you test it but if it can’t be integrated then you’ve caused more work.  We want to be able to efficiently remove bugs for the same reason that you don’t want to spend much time thinking about how you’ll take care of your ant problem. We strive to create reusable code because, why reinvent the wheel?

Code reviews force you to take your audience (your team) into consideration.  You know everyone will be looking at your code so you write the code in a way that is most acceptable to everyone.  This leads to a more uniform way of writing code across a team.  In our case, we have standards that improve readability and usability.

Last, if you avoided that politically charged paper you were going to write in sociology because it was being peer reviewed and you didn’t want to bother anyone…that’s a bummer. You should have done it; but in the software world, controversial writing can cause problems.  You might be tempted to write something lengthy, creative, and complicated.  Writing lengthy, creative, and complicated code can be good…unless the same goal can be accomplished in a short, sweet, and simple piece of code.  If you write something that your teammates have difficulty understanding this will cause short and long term problems and is not likely to impress.

These are the positive changes are made in our code before review time.  Before we even sit down to review our code, it is already better than it would have been without the review.  Once in review, it is refined even more.  During this time we are also able to review code ourselves and learn from each other.  We also spend some time after code review speaking about interesting software topics that we encounter which fosters more learning.  For us, downtime in code review is a good time for joking and team bonding. Most importantly, code review helps us deliver a more uniform, polished product.