Code reviews and Parkinson's law of triviality

emrebeyler (74)in #programming • 7 years ago (edited)

Code reviews are one of the quality measures on software development. Before merging any new code into the main/master branch, related changeset should be reviewed by other developers.

^{Related comic on osnews.}

However, in practice, I barely experienced code reviews are practiced well and constructive.

Parkinson's law of triviality

"Parkinson's law of triviality is C. Northcote Parkinson's 1957 argument that members of an organization give disproportionate weight to trivial issues.[1] He provides the example of a fictional committee whose job was to approve the plans for a nuclear power plant spending the majority of its time on discussions about relatively minor but easy-to-grasp issues, such as what materials to use for the staff bike shed, while neglecting the proposed design of the plant itself, which is far more important and a far more difficult and complex task.". see wikipedia entry

This process is same with the code reviews. If you have a changeset of 3 lines and 1 file, other developers find 10 things to comment. If you have a changeset of 256 lines and 10 files, then it will just past with a good LGTM.

My practices for a better code review

As a lead developer, I am also responsible to make sure our internal processes are working constructively. Here are my practices for better code reviews:

Do not push changesets including 200 files and 15000 lines. These are impossible to review. Use feature flags/toggles and deliver with an iteration.
Do not accept code review comments like "formatting, trivial changes". We have git hooks to automatically check formatting. (Ex: pep8 for Python, "go fmt" for Golang.) If you force them in the "pushing" status, then there is no way you can see a badly formatted code in the pull request.
Do not accept "use X instead of Y" suggestions as long as they're listed on the projects' code conventions or proven to be more efficient.

Should we have code reviews, anyway?

Yes, we should.

Code reviews are awesome. They should be in the process before shipping anything to the live environment. I have seen it helped countless times. However, it should be also a productive process to help the organization.