I already spoke about inattentional blindness in the context of testing in a previous post: Inattentional blindness and test scripts. But there are implications also for code reviews.
So, “We asked 24 radiologists to perform a familiar lung-nodule detection task. A gorilla, 48 times the size of the average nodule, was inserted in the last case that was presented. Eighty-three percent of the radiologists did not see the gorilla. Eye tracking revealed that the majority of those who missed the gorilla looked directly at its location.”(1)
But how can the effects of inattentional blindness can be reduced?
”A more effective strategy would be for a second radiologist, unfamiliar with the case and the tentative diagnosis, to examine the images and to look for secondary problems that might not have been noticed the first time through.”(2)
So, it does make sense to do a code review because things might have gone unnoticed. But with complex systems the important thing is the granularity. This means that we have to understand who makes the review and see possible implications.
For example, let’s say a novice has written some code and another novice will make a code review. The junior reviewer, possibly, will understand where and why that code was written like this. But is it enough? I would say no. A senior/advanced developer have to review the code because:
– can share experience;
– has deep technical knowledge(oop, architecture, clean code, properly deal with legacy code, TDD, unit tests, algorithms);
– is capable to have more perspectives.
Is this still enough? I would say no. A tester can take a look at the code with the intent to help him/her with the testing.
There are some lessons here:
– a novice can participate to a review because is a good occasion for him/her to learn. It will also offer a good occasion to be aware of the context and give a feedback;
– is not ok when the code review is not made by a senior because slowly slowly things will get in such a bad shape that it will be difficult to repair;
– a senior developer might miss certain details;
– a manager should not feel comfortable just because the process does not allow a commit of code in source control without reviews. Even if that process might say something like this: “a review must be made by at least one senior developer”;
– it is related to testing in the sense that the tester is searching for information which will be used in designing the tests;(3)
– this should not be used by developers as an excuse for a lack of professionalism.
This is praxis(4)….
(1) Trafton Drew, Melissa L.-H. Võ, and Jeremy M. Wolfe, Psychological Science September 2013;24(9):1848-1853, “The Invisible Gorilla Strikes Again: Sustained Inattentional Blindness in Expert Observers”: http://search.bwh.harvard.edu/new/pubs/DrewVoWolfe13.pdf
(2) Daniel Simons Christopher Chabris, “The Invisible Gorilla” https://www.amazon.com/gp/aw/d/B009QTTYCQ
(3) James Bach, Rapid Software Testing class discussion [2017]
(4) Dave Snowden, “Of practical wisdom”: http://cognitive-edge.com/blog/of-practical-wisdom/