Code quality. It has been haunting me for so long I forgot when I started to think about it. Do other people think about it? For sure. Do everyone? Certainly not.
I was doing RUP and before that some waterfall process from DoD. Before that I was programming Fortran. Now, what has been my single most important recommendation for reaching code quality?
Peer code review.
But enough. It just struck me how much I do not miss code reviews.
I’ll tell you why and I’ll tell you what is the replacement, because there should be one.
I had completely forgotten about code reviews until I ran into a colleague from the past and suddenly remembered a code review in particular.
It was humiliating. First of all, it was boring to print the code on paper and then spend hours reading it. Secondly, I had to face the fact that a lot of the code was copied but not used. I put a big X across the whole page of dead code. Humiliation became a fact when everyone saw it on the meeting.
It was so boring that despite we were caring about code quality and believed in code review, it was hard to make it happen.
Code review is dead – long live the new code review: pair programming!
There are today two very important practices for code and design quality, one of them is pair programming and the other one is test driven design.
Pair programming is code review because there is somebody looking at the code as you type. If you write code that is either hard to understand or breaks some design rule, it is spotted before you have put down hours into it.
It easier to change something before you get emotionally attached to it.
The old code review also had another downside, the reviewers became attached to the flaws they found. Imagine building up arguments for a position on the design of the code that you think needs to be fixed. You come to the review meeting and the design is already changed. Would you not be tempted to tell everyone what you had found, despite being useless information? I would.
Pair programming is also a setting where two people help each other to solve a problem. A code review is a meeting were a group of people discuss a single persons efforts, the one that was the last to touch the code. I hated it when it was me.
Bye, bye peer code review. Will you rest in peace and not be awaken ever again.
Amen, brother! I have been thinking about writing the exact same blog entry, but you beat me to the punch! I’ve been a strong believer in code reviews, and even blogged about it:
http://www.jroller.com/matsh/entry/template_for_code_review_guidelines
But pair programming is so much better, and so much more fun.
I think I’m in your camp. I really love pair programming and think it’s the ultimate way to share knowledge and learn fast. I also quite like reviewing code via github pull requests.
I’ve spoken to a bunch of googles that HATE pair programming. They say it slows them down. Also this is an interesting post from an ex-googler who thinks your embarrassing experience might be good motivation for you to concentrate harder in future 🙂
http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/
Thanks for commenting and the interesting links. The last from the ex-Google employee, has made somewhat the same observations that I did but arrived at a different conclusion. 🙂
The concept of an author and reviewer sounds really like the old days when somebody was responsible for a piece of the system. I know that Google don’t mean that, though.
Funny argument to say pair programming slows them down while waiting for someone to review their code before checking in, does not! Crazy talk.
An important thing to look for is to shorten feedback loops – and pair programming is a lot shorter loop than code review. The longer the feedback takes, the more expensive it is to fix.