Raiders of the lost art of Software Reviews

John Anderson & Wolf — UK Gladiators
#ifndef EXAMPLE_H
#define EXAMPLE_H
#ident “@(#)example.c 1.3 9/4/96 12:15:13”
/*
**===============================================================
**
** Project Name : XXXX
** Project Number : 1234
**
** File Name : redacted.h
** Ref Number : 1234/T6/PC/0001
** Description : This file contains data types and prototypes
**
** Configuration Record
**
** Review Version Author Date Change No.
** 1970/PM5.7/198 1.1 A Another 10/04/96 Original
** 1970/PM5.7/666 1.2 S Brittain 04/07/96 1970/PM5.9/123
**
**==============================================================
*/
Internal Access Policy in Staff Manual circa 1995
  1. Management reviews — A broad systematic review of the management approaches and artefacts around the software product or development processes
  2. Technical Reviews — A review by engineers to examine the suitability of the product for its intended use
  3. Audits — A review by third party assessors to check compliance against processes and policies
  4. Walk-through — A review by an engineer who leads the team and or other interested parties through the product with Q&A as they go
  5. Inspections — A visual inspection of the software to detect anomalies (e.g. Fagan inspections, Pull requests)
  • Instant — Reviews during development — Suitable for complex tasks. Ideally, the software developers should be at a similar experience level.
  • Synchronous — Review immediately after a unit of work is complete — Great for when the reviewer lacks knowledge of the goal or lots of review comments are expected. Suitable when context shifting is not a significant problem for the reviewers
  • Asynchronous — Review at some point after development — Reduces context shifting issues associated with Synchronous approach.
  • Batched — Review at some later point in time, and change is combining with other changes (e.g. prior to end of sprint) — Great for when a lengthy cycle time between development and comments is not so much of an issue. Must have confidence that code is developed to a high standard prior to review.
  1. No reviews — say no more. A common view is that reviews are not “agile”. Given that one of the fundamental agile principles is “Continuous attention to technical excellence and good design enhances agility”, we can hopefully attribute that idea to pure ignorance.
  2. Reviews being too finer grained — reviews are done only at commit and therefore only look at the problem in isolation. Instead they should be performed at the unit/story level and the Definition of Done used to include an assessment of whether the code is of sufficiently high quality. That’s absolutely not to say that the reviewee may not ask for coaching from the reviewer during the journey to submission, more that it should be a common expectation that submitted code is expected to be at a level of quality sufficient to pass a review.
  3. Reviews being insufficiently interactive — the reviewer does not know whether their comments will actually get reflected back into the code. When Linus Torvalds reviews submissions into the Linux kernel he, as reviewer and maintainer, makes any edits he sees fit and checks them in. The reviewer could, and in many cases should, do the same.
  4. Reviews are conducted only as peer reviews — whilst we all would like to run teams comprising solely of Linus Torvalds clones, the reality is teams will have mixed ability and experience levels. This is a normal and healthy sign if we want to promote important things like personal development, career progression, stretch goals etc. However, teams should not be shy to use the talents and experiences of their most capability developers to educate, provide exemplary leadership and develop others, even if they are self organised as is the Agile norm. This is a clear illustration of maximising return on investement from the most experienced and probably most expensive team members.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store