I used to love getting my essays handed back to me from my teacher. I would quickly look for the red ink comments scattered throughout my paper. I was looking for approval – ‘Yes Jeff, you are truly a genius!’
I do not get the impression that developers either enjoy reviewing co-worker’s code, or having their code reviewed.
Does your organization perform code reviews?
When I poll audiences, it’s pretty rare to get a lot of positive response to that question. I have a couple of ideas why this may be…
Developers don’t like other developer’s code.
They may respect it. They may even re-use it. But more times than not, the first reaction to inheriting someone else’s code is a strong desire to ditch it and re-write it from scratch. Of course there are exceptions. But it IS an exception, right?
Pro Tip: Use a profiler to identify the most expensive part of the program you don’t like, and use pretty pictures to convince your manager to let you re-write at least PART of the program you inherited. Managers are suckers for pretty pictures. (Mostly joking, mostly)
Code reviews are expensive.
It takes a lot of time to review someone else’s code. Developers are getting paid pretty well, and to pull them off a project to go do something OTHER than code – not something a lot of project managers will see as a good thing.
Pro Tip: Build time for code reviews into your development schedules. I know, I know – crazy!
Interesting study – using red pens makes you a jerk.
It turns out that all those formative years spent in grade school having your work marked up in red has conditioned us to be brutal when given the opportunity to mark something up in red. Here’s the study.
Pro Tip: Don’t treat a code review as the Spanish Inquisition. Bringing in the accused to face down a room full of judges is not going to go well. Trust me.
We should still do code reviews!
Having your work reviewed is a best practice. Why should the computer code of an application be treated any differently than the structural design of a bridge? Software bugs can kill people just as easily as a faulty bridge, right? It kind of scares me to know that the only people reading code is the person writing the code. I mean, I don’t feel comfortable blogging without the assistance of an editor – and I’m pretty darn sure my blog can’t kill anyone.
Ok, so maybe you are just building widgets for a website. If someone is relying on your work product to make their business run, that’s worthy of some checks and balances, right?
How do we make it work?
Find the right people to perform the code reviews. We need mentors, not jerks performing this task. It’s a delicate and sensitive enterprise, so don’t give it to the guy or gal that everyone is too afraid to approach for help anyway. Actually if someone is VOLUNTEERING to review code, maybe that’s not the right person?
Tackle the time and cost objections. If you can’t win the argument with common sense – everyone knows that projects spend most of their time and money in the maintenance phase – then try coming at it from a different angle.
If you are a developer, considering asking someone you admire or respect to take a look at your code for you. Instead of a formalized process, maybe you can develop a mentoring relationship. Being the ‘new kid on the block’ who thinks they know everything can be a hard image to shake. Being humble and asking for help is never a bad thing!
…puts on sales hat…
Did you know there are tools out there that can review your code for you? No, a program with rules can’t be as good as a pair of human eyes, but it is arguably better than doing nothing at all! At least the program won’t be offended when you call it an idiot.
