Code Review is an Opportunity for So Much More than Bug Fixes
A recent blog post from the folks at Code Climate (a highly recommended hosted static analysis tool for Rubyists) highlighted a study that found what the researchers deemed “The Unexpected Outcomes Of Code Review”. When I read these “unexpected” outcomes—code improvements, understanding, and communication among colleagues—my initial reaction was “Unexpected? Those are precisely the reason I push hard for an integrated code review process in the first place!”
Then I remembered that I’m apparently a weirdo and have only a rainbows-and-unicorns outlook when forming and wrangling software development teams. Also, that collaborative pedagogy was most certainly beat into me at some point in another life, it takes many forms outside the academy, and the workplace is a pedagogical space. Or at least it should be. It’s more fun that way.
Anyway, if you think about code review processes in software groups, you might think of a process that goes something like this (click to embiggen):
In that bland, flowcharty way (it’s my own flowchart, so I know it’s bland), it may look like the emphasis is on “finding issues”—and of course it is, to an extent, much like the author of the “Unexpected Outcomes” post summarizes that “a large portion of developers, managers, and testers are motivated to perform code review because they hope to find bugs”. But in the era of an increased focus on automated testing, be it through TDD, BDD, or any test automation, code review is an opportunity for so much more.
Although the flowchart boxes are the same, this image shows what I push for in a good, solid, code review process (click to embiggen):
That’s right: unicorns, rainbows, and talking. “Talking” can be entirely through GitHub comments or Jira tickets, or in person, or whatever, as long as it happens. The “unexpected” findings of the study referenced in the blog post are “knowledge transfer, team awareness, and improved solutions to problems [as well as] educating new developers about code writing”. I say that if we (software development managers, team leads, and whomever is making sure the processes are working for your teams and not against them) are not looking for opportunities for holistic improvement, we’re missing out on a great opportunity.
Think back to when your horrible composition instructors in college made you do some in-class peer review. If you were like any student I ever had in class, you probably read a peer’s essay, saw some wonky things, didn’t want to say anything out loud, certainly didn’t want others to find the same issues with your work, and generally thought the whole process was a waste of time. Until—until!—some brave soul piped up and said she was having a hard time understanding your argument, and couldn’t you work together to make it more clear? Or a fellow turned to you and said, “you know, I totally get your point, but you sure do use a lot of extra words to make it!” And with a little teacherly coaching and maybe a worksheet, the flood gates opened, everyone saw they were in this together, and everyone’s work improved. Sure, grammar improved, because it’s easy peasy to fix a sentence fragment, comma splice, or misused semicolon, but so did argumentation, clarity, concision, trust, and the ability to communicate all of that.
It’s easy to find something legitimately wrong with code (it won’t run, won’t compile, tests will fail, etc). It’s more difficult to find and address issues of style, convention, future-proofing, DRY-ing things up, and so on. But those are the real issues that human brains and human eyes should focus on catching, discussing, fixing, and learning about (especially for juniors, but plenty of seniors need help, too). All of those things make our code better, communicating in a positive way makes our teams better (and closer, and more trusting of each other), and it should be a goal, not just an unexpected bonus.
[Unicorn, rainbow, and talky-person clipart by spacefem, laobc, and frankes, respectively.]
All true, and very well put. Personally, I particularly like the effect it has of “educating new developers about code writing”; not just how to write code that works, but code that fits the ethos of the organisation and conforms to the standards (official or otherwise) that the rest of the team expects. If we’re all lucky, those more junior devs will grow into seniors or team leads who propagate the same mindset.
Good post.