I had the occasion a few months ago to climb up onto one of my favorite soapboxes and do a little preaching. The topic centered around code reviews. I was not surprised to find that few had ever heard of this religion but were filled with questions, wonderment, and most anxious to hear the word and see revelations unfold before them.

Not to worry, this is not Dianetics for the software guru but rather one small development technique, a process that can have immense impact on the quality of software you produce as well as offer broad, positive, and measurable effects for an entire development team -- and across numerous products. So this article is aimed not just at programmers but at their managers and their manager’s managers.

The Code Review Soapbox

I attend a game developer’s user group known as Sputnik which meets once a month in Seattle. It is a casual and friendly gathering of game making enthusiasts composed of professionals and beginners, programmers, artists, sound junkies, and the occasional suit. The forum is relaxed and opened to spontaneous tangents and hence it generally covers any and all aspects of the game industry (at least once a meeting!). It’s a great learning experience with a tight finger on the pulse of game development.

This one particular evening we were sharing the secrets and ills and complaints and joys of past or present projects -- thus we were requested to and happily volunteering to air dirty laundry in public. It was great fun and quite educational. But what struck me, and it often does, is that this is an incredibly young industry rot with inexperience. It seems void or somewhat slow to adopt practices that prove nearly essential in other closely related industries.

How many post-mortems have we read touting the god-send of RCS (or Source Safe) like it’s the newest thing? How many times has the Design Document been referred to as the golden book of guidance and everyone should have one? How often do we hear that a Bug Tracking Database was essential and something we should all try? Ever heard of MS Project, Gantt charts, the critical path, or the black art of scheduling? How about meta-meetings or meta-designs? Code reviews? Anyone, anyone? Bueller?

Okay, I don’t mean to be insulting but I am plainly one of those that say the game industry needs to grow up a little, at least in its processes and methodologies. These are all staples used throughout the software world.And yet, here I sat amongst some of the best game developers in the world and though many seem to comprehend the gains and benefits of employing design and code reviews, it came across that virtually none had ever experienced these processes first hand.

The Questions

During the course of sharing secrets and dirty laundry of past and present projects, many real problems were discussed. Common things like what do you do when you lose a programmer or the lead programmer? Do you just throw their code away? Is a team better off tossing it or trying to decipher megabytes of source code? How do you integrate a replacement team member? What can a company do to prepare for (what mistakenly seems to be) the natural migration of game programmers? How can we stop writing and re-writing the same piece of technology? How do we thwart the programmer egos that bury projects? How do we train beginners and hackers? Is there hope that a software team can actually survive two projects? How can I, as a programmer, grow?

The Answer

Code review.

Actually, let me broaden the answer somewhat. Any of the discussion about code review can easily be applied to the design review process, they really work hand in hand. In fact, its difficult for me to conceive one without the other.

Software development, ideally realized, is a cyclic process of refinement and risk reduction. Most projects tend to revisit the design phase during code implementation for various reasons (I view this as actually a good thing). With the reality of milestones, deliverables, demos, and skittish management, as well as lack of complete insight and all encompassing fore-thought, it is the nature in most software projects to have design and implementation occurring in tandem (not to forget occasional visits to analysis-land and bouts of incremental testing).

But for our purposes, I’ll focus on what we seem to love most, and that’s code.

The Question Expanded

So what happens when a programmer leaves a project? Why is it so painful? And is code review really the answer?

Yes! It dices, it slices, its gets the stain out, comes in various scents and flavors, and it even does Windows. Code review is just the product you’ve been looking for! So pick up a box today and let your programmer exits not delay!

So why is it so painful when a programmer leaves a project, especially one that is a major contributor? Consider the typical game developer modus operandi: design a little, avoid meetings, do good work, do it individually, and don’t waste time. An obvious recipe for success, that is, if you’re looking for really stressful days if even one individual leaves your team.

What can a code review process do to help? First off, the process breaks down barriers and encourages sharing. In fact, that’s the essence of code review: open the box, share the knowledge, gain from the experience. No more code ownership. That’s a key element and it deserves more explanation below. But, whoa shit! No more code ownership!! I just lost half the Gamasutra.com readership, didn’t I?

The Answer Expanded

What do you mean show people my code? What do you mean no more code ownership? How am I going to know to who blame for all these bugs?

That’s a scary concept for a lot of programmers, the one about showing people your software. I mean, its your software. You probably never had anyone really look at your code except for a few teachers in high school or college. And I mean really look at your code. When was the last time you sat in a group of people who were critiquing your work, right in front of you, down to the most minute detail, and you were happy and thankful about it? If you work in the game industry, you probably have never heard of that and think its totally absurd.

Ah, but think about it for a second. If all these people are looking at, inspecting, and digesting my code, then when it doesn’t work (or has a few minor deficiencies, a-hem), who do we get to blame? Well crap, it’s not just my fault, by myself, this time. It’s everyone’s fault -- at least everyone that reviewed and approved the code. Maybe there is something to giving up code ownership.

Software development really isn’t about whom to blame when things don’t work. But its one concrete example that actually gets people to consider giving up sole ownership of code. Whatever works.

Exposure

The idea behind a good code review process is that the software is exposed. It is examined at various levels, dissected for various objectives, and scrutinized for all manner of quality (or lack of). The purpose is to recognize defects through inspection. The process is designed to bring the cumulative skill and experience of the entire programming team (over time) to bare on any and every piece of the software. It is the means to harness the strength of the collective and wash away the weaknesses of the individual. A little Trekkie philosophy can go a long way. The Borg have it figured out.

The code review forum also provides an ideal learning environment. Where do programmers today go to learn new tricks, refine their methods, test their prowess, and grow their skill? Primarily its through individual effort, i.e. time-consuming (even career-consuming) trial and error software exploits. Programmers constantly re-write the same technology so they can learn from the experience. Through code review, experience can be passed on, much faster and with much greater variety. And it’s a repetitive process, one that re-enforces good programming practices, one that allows you to teach as well as learn, and it can actually be fun! Yes, its true, code review, a meeting (for god’s sake), can actually be fun. I’ve seen it, I’ve lived it, it really works.