5 Reasons You Are Not Doing Code Reviews
5 Reasons You Are Not Doing Code Reviews
Join the DZone community and get the full member experience.Join For Free
Discover how quick and easy it is to secure secrets, so you can get back to doing what you love. Try Conjur, a free open source security service for developers.
Whether your work in a startup like us at PullReview or in a multinational, getting your team to start doing code review probably got stuck with the typical answer:
That’s a very good idea, but…
Having been there several time, and being quite convinced on the added value of code review, I listed the most common pushbacks I’ve encountered, and some ways to go past them.
...I don’t have time
Of course you don’t. This feature that need to be finished ASAP, and there is a module you want to refactor since months, and that is just the most important stuff…
This is probably the most pervasive answer I get and the one that seems to be the most reasonable. Yet it is not. Opposing deadlines and code quality is a false dichotomy: we insist on code quality because we want to meet deadlines.
In other words: you should always apply and justify best practices to win time (in the form of faster releases or better ones). The convincing (and correct) argument here should always be economical.
As very well put by GeePawHill: We’re in this for the money or as per this Martin’s Fowler slide (talk presented at OOP 2014):
You are finishing the feature, and ready to hand a review. Now, the only available person to take it right now is the young graduate you just hired two months ago. He looks at you and says:
... I don’t have the level to review your code.
That’s not a problem, and you should reassure him: a code review is not a teacher grading a student’s homework. It’s a conversation. Questions have as much values as advices there. No one said you as the reviewer could not be the one to learn something.
As a junior, if he don’t understand something, he’s more than allowed to ask. Maybe he’ll get a nice explanation and learn something, which is good. And maybe it will help you to realize your code is not as clear as you wanted, and he will have helped to make it better.
Now, this is better: you finally finished that feature on project KillerWhale, and by chance, your colleague Andy just ended his own feature on project BuddistBunny. Having worked on all projects in the company, you start to review his code on BuddistBunny, sending him your modifications on KillerWhale to review. Andy was hired some months ago, and is a solid programmer with a very different experience than yours, so you are eager to get his review. Five minutes after, he’s back at your desk:
...can’t do that. I don’t know anything about the KillerWhale project
Of course, your company works on many different projects, and that’s true that Andy never had the opportunity to work on KillerWhale - the only things he knows about the project comes from what he heard at stand-up meetings.
So that’s actually a very good opportunity to get Andy onboard on KillerWhale: he’ll only need to focus on the small pieces of code you just wrote, and there are test to showcase what it should do. You are quite glad of the domain design you did on KillerWhale, and this will be a good test to see how good the naming actually is, as Andy is still an outsider on the project.
So, you’re motivated to start, and want to get this code review practice in the team practices. You just have a meeting with your manager, Peter, so you explain quickly to him that you’ll start doing reviews and how great it will be. Peter is not a coder, so take some time for an explanation about quality improvement. After a short silence, Peter says:
… let me think about first, and get this to the management team.
Peter then goes back to your list of estimation of the last features the customer has asked for.
Of course, getting your boss’s support will always make things easier, especially when you want to spread a practice in a team or whole organization. But remember that ultimately, Peter pays you for your skills, skills that he himself doesn’t have (he has a lot others regarding planning and customer contact). Would you ask Peter whether you should do unit test? Or what library you should use to print PDFs?
At some point, as a craftsman, you’re responsible of your tools and of sharpening them. If you show results, no one will complains. At minima, ask to try it for a sprint or two. The experience will settle it much better that any discussion.
So motivated after getting your first review of Andy’s code, you start looking at your other colleague, Bob, last feature. When you ask him a question, he snap back:
... I don’t need those review things. My code is good enough.
Bob is a good coder, but he mostly work by himself and sees code reviews as a waste of time and a way to control what he does.
There may be a way to work around that: turn the table. Ask Bob for advice on your code. That will get the discussion going, and it may ease him into it. Also, code reviews have a big advantage: they don’t need much to get started. You don’t need everyone in the company to agree - just one single person ready to do it with you once. Should it work well, maybe even Bob will take part. at some point.
I've setup code reviews in very different environments, and everytime it did bring something valuable to the team. I'm still reviewing code everyday here at PullRview, and it's a practice I'm taking with me everywhere I go.
Published at DZone with permission of Martin Van Aken , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.