Code Reviews and the Gym: Plenty of Reasons Not to do Either - None of them Good
Yes, I’m fully aware of the benefits of a healthful lifestyle including proper diet and plenty of exercise. And yes, I can easily come up with a thousand excuses to NOT work out. I can probably write volumes of excuses.
And as a former software engineer and engineering manager, I’m similarly aware of the benefits of code review on a development team’s health:
- Defects caught earlier, when they’re less expensive to fix;
- Better structured, more maintainable code;
- Knowledge sharing and mentorship;
- Fewer defects getting to QA;
- And my favorite… catching defects when they’re QUICKER to fix… which is really the first point, cast in a different light.
And just like starting a workout regime, I’ve heard all sorts of reasons why organizations don’t adopt code review as a core practice. Personally, I think there are a lot of myths floating around; so many myths that I could write a book – and I may – but I’ll start by going over just a couple.
The first myth is that code review is a “dead” practice…. that code reviews are “old school.”
Sure, I’ve worked places where we didn’t have a formalized code review practice. In cases where our product was GOOD, it wasn’t that developers didn’t review each other’s code, it was just that there wasn’t a formalized procedure to do so. We mostly did over-the-shoulder reviews when we had something that needed consultation. Mind you, these were always small, co-located teams where the communication among team members was exceptionally fluid.
I’ve also worked in organizations where the developers WANTED to institute code reviews (yes, I said the developers wanted to institute code reviews), but the management didn’t support them. This brings me to another myth: Code review is always brought in by upper management, and foisted on the development team, who resent it.
When I was a junior developer, I was grateful for the tips and tricks those more senior to me gave me. As I became more senior, I was happy to pass on my knowledge to others. I really don’t think I'm all that unusual.
Sure, there are some hackers that don’t want to expose their work to others - makes you wonder what they’re ashamed of. And there are jerks that make more snarky comments than useful ones while performing reviews - makes you happy you only work with them, and don’t live with them. But, by and large, developers want to do the best job possible, want to increase their skill, and want to share their knowledge with others.
For these developers, implementing the user stories isn’t just about coding up the features. It’s also about making sure it’s quality code. It goes without saying that the code should be computationally accurate; if it fetches data, manipulates it and displays the result, it has to display the correct result. But it should also be well-structured (so it can be easily understood and enhanced later), it should be performant, it should not introduce security vulnerabilities, and um... it should actually manifest the desired functionality!
All of these characteristics can be improved through peer review. Developers with expertise in performance can practically feel the sluggishness in a poorly designed algorithm. Security experts know the anti-patterns for vulnerabilities, and can see them as though they were glowing neon signs. Code reviews are a great way to improve the application by having more senior staff sharing their knowledge with the less experienced.
And everyone benefits.
So why don’t organizations perform code reviews? Well, first of all, who says they don’t? As my colleague Lorinda Brandon indicated in her post last week, SmartBear recently conducted a large-scale survey on code review practices. We had more than 600 respondents answer 39 questions on their current and prior use of code reviews. And we learned some very interesting things, which she and I will share during a webinar on April 17. One of the things we learned is that 70% of the respondents actually DO code reviews. That’s not a small number.
Myth #1: Debunked. Code review really IS a well adopted practice.
Also in the survey, we asked those that don’t do code reviews why they don’t do them. They gave us some interesting answers to the choices we gave them:
But even more interesting were some of the free-form answers they gave us:
- “There is no culture for it in the company.”
- “Manager only wants results. Doesn’t care about internal software quality.”
- “We don’t have the leadership”
And my absolute favorite: “We’re dumb.”
While we did have managers responding to our survey, the vast majority were practitioners. To me, these comments are indicative of developers wishing that they could institute code review practices in an environment where there is resistance … but not necessarily from other practitioners!
Myth #2: Debunked. When there is resistance to code reviews, it’s not necessarily from developers!
It’s hard for me to fathom, but for some organizations, velocity is more important than quality. The developers are driven by management to implement a large number of user stories, not necessarily to implement them well. Perhaps for these organizations, they perceive that they don’t have time to do code reviews, even when it’s well documented that code review actually shortens the development process by delivering higher quality code into the lifecycle.
At this point, you may be wondering if Agile organizations, because of their rapid development cycles, tend to adopt code review more frequently or less frequently than the average. Well, thanks to our survey, I know the answer to that too!
But before this post turns into the book I was threatening, I need to get to the gym, so allow me to suggest that you join Lorinda and me on April 17 for our webinar, where we’ll reveal this as well as talk more about what type of organizations do code reviews above the norm, why others don’t, and how performing code reviews relates to their code quality.
And of course, if you’d like to share YOUR thoughts on why your organization does or doesn’t do code reviews, please comment below.