It’s easy to get on the code review band-wagon, and tout it as the “silver bullet” for bugs, or the key to developing awesome, elegant software, etc. It’s easy to get carried away, and forget that code review should probably be accompanied by rigorous testing, static analysis, and security integration from day one.
While the purpose of this blog post by Shawn Hernan from Microsoft may be to attack or question the merits of open source software, I see it as an interesting discussion on the role of code review in software engineering and how it relates to writing secure code.
Insert your own joke about Microsoft security here. I, personally, think their IE team should read Shawn’s post.
Particularly interesting is one of the comments to the post by “danclarke_2000”:
I think another point is diminishing returns of code review.. Each extra code review brings less value than the preeding; review comments can already be known and awaiting action, not important enough to change etc
having extra eyes reviewing code means generating extra code review output. Here is the true cost, all the code review comments of the many eyes have to pass through the bottleneck of the few people who have authority to make changes. As each extra review has less value, processing the extra reviews has a higher and higher opportunity cost.
Anyhow, Hernan’s post is an interesting read. Click here to check it out.
UPDATE:
Here’s a quote from Joshua Bloch of Google on a similar topic:
…We programmers need all the help we can get, and we should never assume otherwise. Careful design is great. Testing is great. Formal methods are great. Code reviews are great. Static analysis is great. But none of these things alone are sufficient to eliminate bugs: They will always be with us. A bug can exist for half a century despite our best efforts to exterminate it. We must program carefully, defensively, and remain ever vigilant.