Presentation from the August 2012 NBIC (Netherlands Bioinformatics Centre) BioAssist programmer's meeting. Overview of the content: 1. what are code reviews, some different ways of reviewing code 2. why would you want to do code reviews, what makes sense and what not 3. how can you do code reviews (or formal inspections), some real world experience 4. using tools for code reviews 5. some links for more information 6. two bonus slides with a few links to gems from the Triumph of the Nerds documentary, well worth watching!

1. Code Reviews: what, why and how
An short introduction to code reviews.
August 17th 2012
Freek de Bruijn (NBIC)

2. Presentation overview
• what are code reviews, some different ways of reviewing code
• why would you want to do code reviews, what makes sense and
what not
• how can you do code reviews, real world experience
• David will assist us to review the D2RQ project this afternoon
• we want to invite you to present a project for code review in a
future meeting

3. WTFs/minute - Thom Holwerda

4. What are code reviews?
• take a fresh look at the source code
• goals: improve quality, remove bugs and share knowledge
• different ways:
• informal walkthrough (author leads through code)
• pair programming (continuous or occasional)
• formal inspections (extremely thorough)
• discuss informally with a group like this: preferred ways of coding, in-
depth presentation of a project
• focus is on overall design, class structure, understandable names,
optimal use of libraries, applicable design patterns and elegant
code
• focus is not on things you can automatically check with tools (like
for example CheckStyle, FindBugs and PMD for Java code)

5. Why do code reviews? (1 of 3)

6. Why do code reviews? (2 of 3)
• find and fix bugs as early in the project as possible
• have constructive discussions on improvement opportunities
• learn from studying each others code
• distribute knowledge: collective code ownership
• educate new team members
• enhance team spirit and grow collective values
• it just makes sense, like peer reviewing scientific articles

7. Looking forward to a code review - Todd Presta

8. Why NOT do code reviews? (3 of 3)
• doing code reviews take a serious investment and changes the way
you work
• it takes too much time to really understand new code that does
anything non-trivial
• developers prefer to spend their time on “their part” of the system
• most of the feedback is very general and/or focuses on minor
details
• the team is too small to do effective code reviews
• the code will only be used for a short period (or will it?)
• management does not believe in code reviews
• the code is already very good, there’s hardly anything to review…

9. Be positive - Cyanide & Happiness

10. How can you do a code review?
• be constructive and positive!
• different ways:
• informal walkthrough (author leads through code): transfer code,
introduce new team members, explain to a colleague why you think the
code should work… ;-)
• pair programming (continuous or occasional): it is part of the process to
look at the code and discuss different approaches
• formal inspections (extremely thorough): next slide
• discuss informally with a group like this: we will try it out by looking at
the D2RQ code this afternoon
• you are welcome to suggest a (or your) project for a future code
review

11. How can you do a formal inspection (IEEE 1028)?
•management preparation
•planning the review
•overview of review procedures
•[individual] preparation
•[group] examination
•rework/follow-up

12. Using tools to support code reviews

13. Where can you find more information?
• interesting articles on Coding Horror with lots of comments
codinghorror.com/blog/2006/01/code-reviews-just-do-it.html
codinghorror.com/blog/2007/11/pair-programming-vs-code-
reviews.html
• Code Review and Software Review described in detail on Wikipedia
en.wikipedia.org/wiki/Code_review
en.wikipedia.org/wiki/Software_review
en.wikipedia.org/wiki/Fagan_inspection
• free book “Best Kept Secrets of Peer Code Review” from SmartBear
Software (this company offers a code review tool)
smartbear.com/solutions/white-papers/best-kept-secrets-of-peer-
code-review

14. Any questions?

15. Bonus: culture at IBM (around 1980)
• Triumph of the Nerds (part 2, 5:30-6:52)
youtube.com/watch?v=IbRmaIzGTOM
pbs.org/nerds/part2.html
• “IBM is like Switzerland -- conservative, a little dull, yet prosperous.
It has committees to verify each decision. The safety net is so big
that it is hard to make a bad decision - or any decision at all.”
• “Rich Seidner, computer programmer and wannabe Paul Simon,
spent twenty-five years marching in lockstep at IBM. He feels better
now.”
• “At one point somebody looked at the process to see what's it doing
and what's the overhead built into it, what they found is that it
would take at least nine months to ship an empty box.”

16. Bonus: culture at a small startup (around 1980)
• Triumph of the Nerds (part 1, 6:31-7:18 and 8:49-9:05)
youtube.com/watch?v=CFL9IyJ_qHk
pbs.org/nerds/part1.html
• “Their hobby is their business and the culture they've created is
identical to that of a thousand other technology companies. First,
they dumped the idea of nine to five. In this industry, you can work
any 80 hours per week you like.”
• Doug Muise (Software designer): “Eating, bathing, having a
girlfriend, having an active social life is incidental, it gets in the
way of code time. Writing code is the primary force that drives our
lives so anything that interrupts that is wasteful.”