interesting entry praising Pair Programming and criticizing code reviews. Take a look if you want to get a counter-opinion to mine, but in general, I find that Brian’s arguments are a demonstration that blocking code reviews are not optimal much more than he demonstrates that pair programming is the right solution. I think that non-blocking code reviews have all the characteristics of a happy medium between these two radical approaches.
What about code ownership?
Shared code ownership is vastly over hyped.
Shared code ownership is presented as a desirable consequence of Pair Programming and it simply means that since at all times, there has always been at least two people working on the same region of code, the entire team has a much better knowledge of the code base and that everyone can therefore step in at any time to fix a problem even in the absence of a key member.
First of all, reasonable shared code ownership can be reached with peer reviews. It’s pretty easy to see why: when you spend some time reviewing a teammate’s code, you gain a very familiar knowledge of it, and it won’t take you long to dive back in if you need to.
But more generally, shared code ownership is simply unnecessary if the code has been written by competent developers under careful code reviews. It is very common for me (at least once a week) to stumble upon an area of code that I’ve never seen before, and I usually have no problem finding my way around it if the developer has followed some simple rules (commenting, naming the classes, methods and variables appropriately, using design patterns, etc…). Code reviews will buy you a micro-knowledge of the code, but I find that I usually don’t need to know the code in so much details most of the time.
Finally, if you need a proof that code ownership is vastly over hyped, look no further than open source projects. In typical open source projects, reviews are not mandatory and everyone can check in code at their will. New developers come and go and they don’t seem to have much problem learning the new code base, assuming that’s it’s been commented and written with good design principles.
If your organization is not mandating code reviews, you should reconsider this decision and, ideally, opt for non-blocking code reviews. There are various other ways to implement code reviews that I did not cover in this document, but whatever you choose, make sure that members on your team regularly get exposed to code coming from other members, even if superficially.
How about yourself? Are you doing code reviews in your company?