Social Aspects of Peer Review

Happy Monday! Here's some light reading to start your week with.

I stumbled across a paper titled "Social Aspects of Code Review". Peer code reviews are something I am very fond of - I want to have the least bugs possible in my code. This paper dives into managing the social aspects of code review on your team (i.e. minimizing bruised egos and fear of judgment). The paper also provides many pro-review arguments for those who are still on the fence.

Get your team started with code reviews if you haven't already!

Read the paper here.

The Best Quote:

The reviewer and the author are a team. Together they intend to produce code excellent in all respects, behaving as documented and easy for the next developer to understand. The back-and- forth of code-and-find-defects is not one developer chastising another – it’s a process by which two developers can develop software of far greater quality than either could do alone.

My Notes & Highlights

  • “Ego Effect”
    • Nobody wants to be called out or made to look bad, so knowing you have to have your code review applies more pressure
      • You become a better developer immediately
    • Spot check reviews don’t work if there’s not a high probability of getting checked
  • Reviewing is a chance for the reviewer to learn new techniques, APIs, etc.
  • Old Habits die easy
    • Note what issues your reviewers bring up a lot, and work on fixing those.
  • Big Brother Effect
    • Don’t use the metrics against your team
  • Hard code has more defects
    • If you know a piece of code is complicated and a reviewer has no flaws or comments or questions - that reviewer is probably not being diligent.
    • This has nothing to do with developer productivity/ability
  • More time spent on review yields more defects identified
    • Social aspects of review claims defect density finds increase until ~30min mark
    • Most people don’t review long enough!
    • Reviewers who spend more time on code reviews ought to uncover more defects.
    • This has nothing to do with developer productivity/ability
  • The goal of reviews is to make the code as good as possible.
    • All humans are fallible
    • Mistakes will be made no matter how experienced or careful you are
    • The take-home point is this: Even with many, very intelligent and experienced people, mistakes will be made. NASA addressed this problem in nine parts, most of which are forms of review. The point of software code review is the same – to eliminate as many defects as possible, regardless of who “caused” the error, regardlessofwhofoundit. Thisisn’tpersonal.
  • The more defects you find the better
    • After all, if finding a defect means a Challenger disaster is averted, than finding defects is good. If we expect defects in important or complex code, finding defects in that code is good. If reviewers naturally find more defects when they’re diligent, higher numbers of defects are good.
    • The reviewer and the author are a team. Together they intend to produce code excellent in all respects, behaving as documented and easy for the next developer to understand. The back-and- forth of code-and-find-defects is not one developer chastising another – it’s a process by which two developers can develop software of far greater quality than either could do alone.
    • The more defects that are found, the better the team is working together. It doesn’t mean the author has a problem; it means they’re both successfully exploring all possibilities and getting rid of many mistakes. Authors and reviewers should be proud of any stretch of code where many defects were found and corrected