Is Gaming the Hottest Bed of Innovation in Software Development?
Test and Monitor | Posted June 24, 2013

It’s really hard to put game developers in a box, so sitting down to write this blog sent my mind in a million directions. Games are infiltrating everything, and the more I think about it, the more I see how important it is that game developers produce software that really works the way they envision it—whatever it is they are doing. Why? Because, at this point, the gaming industry truly spans an enormous breadth of topics and industries—from entertainment to exercise to education—and is influencing the development of far more.

I'd go as far as to say (as you may have seen in the title) that gaming is the hottest bed of innovation for software development itself. I admit this is a purely anecdotal assumption, but I have two good reasons.  Game developers have always been at the forefront of interactive software, both pieces within the game interacting together and different pieces responding to user commands—and that has spawned breakthroughs in very important areas like medicine, security, navigation, etc.

Secondly, because it’s considered entertainment, game developers get to be extremely creative, visualizing fantasy realms and finding ways to make them real. While I do think all developers are inherently artistic, game developers embody the archetype and seem to be able to take artistic leaps that other software cultures don’t foster. That kind of open artistic license to take an idea to the limit has had both very positive and very negative effects— such as coming up with amazing new ways to help some children learn while causing debilitating addictions in others. It’s been a messy process, but I’m convinced that the good is outweighing the bad, mostly because we are seeing the completely inspiring possibilities of getting it right.

All of this makes me a major cheerleader of code review for game developers, not just because they/we want their games to work right, but because they are influencing the development of software as a whole. And they need to foster a culture of quality along with their culture of innovation.

If you are a game developer and already do code review, hurrah! If you’re not or if you need to improve your existing practice, here are some tips to get you started that have been gleaned from years of researching existing code review studies and conducting some of our own— including the world’s largest-ever published study on code review, encompassing 2,500 code reviews, 50 programmers, and 3.2 million lines of code.

One more word on that huge study we did. The main reason we conducted it was to test out a theory for best practices and time efficiency SmartBear founder, Jason Cohen, called “lightweight code review.” We found that developers can review code in 1/5th the time needed for full “formal” code reviews and even end up with better results (see #4 below). Considering the code complexity and deadline heavy conditions most game developers are under, I thought these techniques would adapt perfectly to reviewing game code, with a few additions…

9 Code Review Tips for Game Developers

  1. Choose your team wisely and designate a memory expert. Games are heavy on graphic elements that eat up memory, so be sure to have a memory expert on your code review team. Memory allocation errors and not meeting memory requirements are one of the most common late-in-the-game crisis points that create panic among teams. Having a memory expert, or someone who is tasked to specifically focus on memory can greatly help ease that tension.
  2. Check for inelegantly coded interactions and logic errors. Character interactions within a game and with the player make for extremely complex code. It’s best to dedicate one or more reviewers to specifically look for inelegantly coded interactions.
  3. Avoid conflict. While not isolated to game development, the complexity of typical game code can lead to conflicts more frequently than some other types of applications. During your code review, look for instances where identifiers may conflict - even if you have not run into conflicts yet, make sure that the identifiers scheme you are using will scale for future development. The name mapping conventions used should be the same between developers and testers at the beginning of development.
  4. Less is more - lightweight code review. For optimal effectiveness, developers should review fewer than 200-400 lines of code (LOC) at a time. Beyond that, the ability to find defects diminishes. Also, don’t review for more than 60-90 minutes. After about 60 minutes, reviewers simply wear out and stop finding additional defects. Aim for an inspection rate of less than 300-500 LOC/hour. Reviewing faster than 400-500 LOC/hour results in a severe drop-off in effectiveness.
  5. Review your own work first. Authors should annotate source code before the review begins. Because the author has to re-think and explain the changes during the annotation process, the author uncovers many of the defects before the review even begins, making the process far less painful for everyone.
  6. Set goals and capture metrics. Establish quantifiable goals for code review and capture metrics so you can improve your processes. Once you’ve defined specific goals, you will be able to judge whether peer review is really achieving the results you require. It’s best to start with external metrics, such as “reduce memory allocation by 20%.” But, you also want to watch internal process metrics to get an idea of how many defects are found, where your problems lie, and how long your developers are spending on reviews. The most common internal metrics for code review are inspection rate, defect rate, and defect density.
  7. Make a checklist. Checklists substantially improve results for both authors and reviewers. They remind the reviewer or author to take the time to look for something that might be missing. A checklist will remind authors and reviewers to confirm that all errors are handled, that function arguments are tested for invalid values, that unit tests have been created, etc.
  8. Verify that defects are actually fixed! I know it’s obvious, but sometimes things just fall through the cracks in our busy lives. Make sure to verify, so all your hard work isn’t lost.
  9. Award instead of punish. Managers must foster a good code review culture in which finding defects is viewed positively. Code review can do more for team building than almost any other technique we’ve seen – but only if managers promote it at a means for learning, growing, and communication. Fostering a negative attitude towards defects found can sour a whole team, not to mention sabotage the bug-finding process.

These tips should get you started on your own code review process or at least get you thinking about the experience you’ve already had. I’d definitely love to hear your take and input on this subject. Help out your fellow game developer—and all who they inspire—by offering your advice in the comment section.

See also:


By submitting this form, you agree to our
Terms of Use and Privacy Policy

Thanks for Subscribing

Keep an eye on your inbox for more great content.

Continue Reading

Add a little SmartBear to your life

Stay on top of your Software game with the latest developer tips, best practices and news, delivered straight to your inbox