By John Hunter, author of Management Matters: Building Enterprise Capability.
Software code review is the practice of reviewing the software code written by colleagues on your software development team. Like many practices the form it takes can vary quite a bit.
W. Edwards Deming stated in Out of the Crisis:
Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.
Does this mean code review is unwise as it is, in some ways, similar to inspection?
I think the “inspection” in code reviews is different enough that we can use code reviews as a valuable tool for managing software development. The waste of having processes that create defects and then use inspection to catch them is certainly something to avoid. A significant part of the effort in code reviews should be geared toward capturing learning that can be applied to current processes to improve them so fewer bugs are created in the future.
In my experience this part of code reviews (using it to improve the existing processes) is not given the focus it should be. So I do believe that code reviews should focus more on why did we find something we decided to fix?
Do we need to update a software development checklist?
Do we need to update our coding conventions document to add more detail or make something clearer?
Do we need to encourage developers to seek out advice when they are uncertain?
In my opinion, using software code reviews to learn and possibly get input is certainly good. This is a form of coaching that is done using the code review process which seems perfectly fine to me. It is an outcome of the code review process that is beneficial and shows it to be not merely a process to catch defects.
Code review as a method of achieving quality (avoiding bugs etc.) is something worth thinking about. As I see it, the practice can make sense given the process of software programming is highly dependent on thoughtful action by a person and is subject to error due to the difficulty of the task. It is different from say, welcoming a guest to the hotel where you really don’t have to worry that if people are trained properly and given reasonable processes and work conditions that they will make a significant error. The software development process isn’t quite so certain.
I do think that you could redesign the process to encourage developers to seek advice on coding issues they faced when they were uncertain (as part of a non-inspection process just a matter of seeking advice on a challenge they faced). To the extent an organization finds code reviews provide a way to allow this to happen but in a way that can seem more like inspection than seeking advice I think it is fine. How you design the process to achieve this end just depends on what makes the most sense for each organization. In my experience usually both happen (people know they can ask questions when they have them but also realize on some issues they can just wait until the code review to discuss an issue).
For a code review process I recommend emphasizing the importance of
- learning from code reviews – treating the process as a matter of coaching where all the participants can learn from each other
- adopting improved processes (so perhaps use try-catch in those situations, so improve the code here but also agree that we will take care in situations similar to this to use try-catch in future code)
- categorizing those items that are caught to be fixed and figure out how to adopt new processes to avoid the (perhaps – less guessing in the coding, go ask a senior developer when uncertain… or add items to a checklist for… or naming conventions need to be extended to cover this area where they are unclear… or test coverage missed x so fix that and also the process improvement might be that remember test coverage in such and such situation should include…).
Basically relying on code review to catch bugs is certainly not ideal (even doing it well people will naturally miss things). But maybe even this aspect of software code review is worthwhile. The process of writing software code is complex and it may well be that we don’t have sufficiently reliable processes currently that mean completed code is of a level that code review to catch issues is not valuable. Certainly we should continue to try and improve our processes to reach such a level. Even so, given the other reasons code reviews provide value there may well not be a need to look at eliminating them.
Using code review in different ways for different people makes sense. For developers creating code that are more likely to benefit from help (and for which the end product is more likely to benefit from more eyes looking at the code) the code review can be more comprehensive. For developers working on code that we have evidence will not benefit from code reviews, do less, or no code review.
As mentioned above in some cases software code review is similar to part of the process for creating the final product, it is not an outside-the-process inspection after the fact. For example, if developers chose what to review that is similar to either coaching (look at this cool thing I did so you can learn and use it) or consulting a colleague when you are not sure what to do (look at this code and this need – I can’t figure out a way to accomplish x or this way I accomplish x seems like it should be improved, can you help improve it).
Another case can be similar to coaching people who are being brought up to being “fully autonomous” (conceptually). So in some cases it would be like having a person doing new tasks (waiting on a table, completing a heart transplant or whatever) and having an expert watching to
- give them guidance after the fact on what they noticed by sharing their thoughts
- be able to discuss the situation with the employee after the fact based on first hand knowledge (I wasn’t sure what to do, but I did x – is that right, what should have done instead…)
- just take over and do whatever needs to be done if that is required based on how things unfold
There are also simple kinds of learning that are also benefits of code review
- less experienced (in general or on some particular area or item) people can gain insight from those with more knowledge on good tactics or strategies.
- people can learn from seeing what others do (those more skilled or even just with different ideas on how to attack something)
If code reviews are finding simple errors of the “inspection catching a bug to achieve quality” that is likely largely (but maybe not completely given the complexity of the task) an issue that should be addressed by improving the processes. My guess is in a very well operating software development system (focused on Deming, good software practices…) code review would not be needed to inspect for quality. Largely, I believe it would be replaced by a very similar practice that just seems less “inspection-like” – one where developers ask for guidance when needed: asking for confirmation that this tricky code does in fact seem a good solution to the task at hand and ask to present some code others may benefit from seeing when needed.
In my experience code reviews are worthwhile. In my experience they have been not 100% inspection but instead code selected by the developer to be reviewed based on their knowledge that doing so may provide value. This is fairly different from the idea of inspection at the end of a process to separate the defects from the good items to remove defective items from those that will be delivered to customers. Though I can see how they could be seen as similar processes.
Most importantly, organization should think about what works best in their system. And thinking about the idea of eliminating inspection to achieve quality by instead improving the processes to produce quality without inspection is a sensible aim. How that manifests in your organization needs to be a matter of thought and experimentation. And it may well change over time as your organization changes.
I would be interested in other’s thoughts about how to view software code reviews within a Deming management mindset. Please add your comments below.
Related: Deming’s Management Practices and Software Development – What’s Deming Got to Do With Agile Software Development and Kanban – Code Reviews Don’t Produce Quality Code – Improving Software Development with Automated Tests – Customer Focus with a Deming Perspective