Triage Changes to Manage Risk Using Code Reviews

Code reviews need to happen in-band with the main development & deployment process. To do otherwise limits their effectiveness and generates resistance–like every other out-of-band task that interrupts flow.

Tests and code coverage, linting, and complexity metrics are some of the tools we can use to help focus our code review efforts, and I believe there is a lot more these tools can do. For example, I would love to have rules for creating function names. Good function names should start with a verb–it’s not that difficult to enforce that rule, and you could easily establish a vocabulary of verbs to use across projects. Similarly, the nouns should reflect the problem domain, with the vocabulary building up as the tests and code evolve. This would be much better than the simple, naive autocomplete suggestions currently provided by editors–as useful as that feature is.

Anyway…If it’s not possible to inspect 100% of code changes, something else is required to maximize the overall effectiveness of code reviews. The key terms here are triage and risk. Triage is fast and simple sorting, based on obvious indicators. Risk is the probability of loss or damage due to an adverse event.

To most effectively allocate your code reviewing time, you triage changes to manage risk:

  • Changes that impact security incur high risk.
  • Changes that impact more critical functions, incur a higher risk than changes that impact less critical functions.
  • Changes that impact more frequently used functions incur a higher risk than changes that impact less frequently used functions.
  • Senior engineers will make fewer mistakes than junior engineers performing the same task. Consequently, you’d like to scrutinize their work a little more closely. Code reviews are also teaching opportunities.
  • An engineer will introduce more defects into a complex function than a simpler function. Consequently, you’d like to limit complexity and scrutinize changes to complex functions more than others.
  • A more intensive change incurs a higher risk than a simpler change, but keep in mind that even the smallest change can have major consequences.
  • Everyone’s code needs to be reviewed once in awhile.
  • All code should be reviewed every once in awhile.

If you use BDD, then you should be able to identify your most critical, service-defining scenarios.

Advertisements

About jeffmershon

Director of Program Management at SiriusXM.
This entry was posted in Software and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s