At Third Kind Games, we made the decision to not employ a rigorous (and often tedious) buddy review system – rather, we have relied on other methods of ensuring code quality:
- Swarm tightly integrated into our Slack messaging system
- Programmers are responsible for understanding when they need help or advice, whether in their own systems or in new territory
- Daily playtests
I believe this approach has had mixed but overall positive results and I am pretty happy with how we are working. I feel I am less distracted by other programmers requesting buddy checks, and I don’t think my code quality has significantly dipped.
However, while reviewing some of my older musings on programming I came across a short piece I had written which I thought may still have some merit to the wider community; even though it relates to something which Third Kind Games are not necessarily using so much. Here is the article and I would love your feedback!
Buddy Reviews Should Happen in Two Parts
In many companies, the “Code Walkthrough” buddy process is the weapon of choice when it comes to buddying code.
The “Code Walkthrough” typically involves a programmer finishing a chunk of work, be it significant or trivial, and requesting another programmer to sit at their desk where they will have the new work explained to them. The reviewer will make suggestions where appropriate, discuss some of the design reasoning, then where applicable give it a cursory test (manual or automated) before signing off.
But only barely.
The amount of bugs I have seen slip through the gaps here is staggering. I believe that one of the myriad reasons for bugs creeping through is a very human one: I am not in my comfort zone when I am sitting at your desk.
At a strange keyboard,
Your breath down my neck,
Do I really understand this code which took,
Similarly to being introduced to another person and you don’t understand their name at first, after three repeats you may give up and hope it doesn’t come up again; I believe people often feign fully understanding technical issues for fear of looking foolish or less intelligent in front of colleagues. Mileage may vary, for sure; some people are more comfortable asking tough questions, they relish in immediately being able to call out a colleague on whether they have just re-implemented an std algorithm but less efficiently. But not everyone is like this. Some people need more time, more space, some people are just not great when under the pressure of immediate comprehension.
I believe that if your company is employing a “Code Walkthrough” process they need to tack on an additional phase for private review and comprehension. The files should be shelved and the reviewer can sit at their desk, with their ultra-wide monitor and noise cancelling headphones (playing the most excellent of technical metal, of course), compile the code, step through it where necessary, use their code comprehension tool of choice, their syntax highlighting; the personal touches which many programmers have a very certain affinity to.
Personally, when using this process, I have never failed to find a new bug, an invalid assumption, or a hidden dependency. As we all know, the later a bug is found the more expensive it is to fix. The amount of time to submit the files, get a build made, get it into QA, discover the bug as part of routine or ad-hoc testing, reproduce it, write it up, submit it to a lead, pass it to a programmer and then wait for the programmer to get time to fix it, buddy, submit, regress… is orders of magnitude greater than an extra pre-commit check.