16 June 2011
Making the case for code reviews
Peer review of code can be a powerful software quality assurance tool. It helps to spread knowledge, encourages readable code and helps to find bugs before your QA team do. Given the obvious benefits, why can it be so difficult to implement?
Most people who have worked in environments with regular code reviews would never consider abandoning them. However, introducing code reviews into a new environment can be fraught with difficulties. People often don’t understand what code reviews are or what they stand to gain from them. There can also be numerous cultural barriers as well the inevitable inertia that is caused by plain old resistance to change.
A common form of resistance is “not applicable here” syndrome where people spend considerable energy explaining why reviews are not necessary or won’t fit with the prevailing culture. Projects will be too small, there won’t be enough time or process will be too sophisticated to fully benefit from archaic manual checks.
When making the case for code reviews you will need to provide a concrete, benefits-driven justification for them. You will also have to address any cultural or process issues that will undermine any attempt to introduce them. Winning the argument is not enough – you need to clear the way for adoption too.
Positioning peer reviews as an efficient testing technique
The main goal of peer review is to improve the overall quality of code so it should be seen in terms of your overall investment in quality assurance. However, when considering quality assurance strategy peer review can often be overlooked in favour of more formal testing methods.
The outputs of formal QA testing tend to be valued more highly than the more esoteric outputs of code reviews. Peer reviews tend to focus on code-related errors so can often appear rather abstract or even irrelevant to non-technical audiences. The formal testing carried out by QA teams tends to deal with more tangible issues such as visual feedback from interfaces making it easier to relate to.
These perceptions are false as peer reviews can be an important influence on the overall stability and quality of the system. There is much evidence to suggest that peer review is a very efficient means of detecting bugs – perhaps more so than formal testing.
Steve McConnell suggested in his book Code Complete that software testing alone is not as effective at finding defects as peer review. He measured the average detection rate from unit testing at 25% and 35% for functional testing. Design and code inspections by peers on the other hand had a detection rate of 55-60%.
The case studies offered by McConnell are impressive. A study involving more than 200 people at AT&T reported a 90% decrease in defects and a 14% increase in productivity after introducing reviews. A more extreme example is IBM’s Orbit project which yielded around 1% of the errors that would normally be expected after introducing eleven levels of code inspection.
Code reviews are clearly more than just a technical indulgence. They are an efficient means of detecting errors and can also serve to improve the productivity of a development team.
Encouraging “egoless programming”
The culture of the team and attitude of developers towards their work can be an obstacle to effective peer review. Developers often make an emotional investment in their work and can tie their sense of self-worth into the code that they produce. This can cause them to interpret any faults in their code as a personal weakness that exposes their professional shortcomings.
In order to guard their egos developers can become protective and resist detecting bugs even going so far as to deny the possibility of any bugs. This kind of ego-protection is a barrier to effective code review. It encourages an attitude of private ownership of code which undermines the quality of the overall team’s output.
Gerald Weinberg talked about the concept of “egoless programming” in his book The Psychology of Computer Programming. Developers should be encouraged to take a step back and develop a more “egoless” approach to their work. They should embrace the input of their peers and develop code that is easy for other people to understand and work with.
This requires a culture of collaborative teamwork and the open exchange of knowledge. Developers should still be encouraged to trust and defend their work – after all, this is “egoless programming” rather than “egoless programmers” – but they should learn to recognise that they make mistakes and that the quality of their work will benefit from an external perspective.
The need for a blame-free culture – and measurement
A major cultural barrier to code reviews among developers is the fear of ridicule if the number of errors in their code is exposed. It is important that developers should not be blamed for errors while they are being encouraged to be open about their work. If developers are going to embrace an open approach then management should foster a supportive environment by ensuring that code reviews are not used to assess developer performance.
All this hinges upon the need to gather evidence. Many developers simply do not recognise the need for peer reviews as they are not aware of the mistakes that they are making. Many organisations do not collect and publish basic information about errors so developers do not realise how many errors are being found by QA or – worse still – clients.
Filed under Development process.