Here at Initech, I recently wrote this document and passed it around to other development managers, to much applause. Since I’ve had so much success with it, I thought I’d share it here with a larger audience.
Code review is amongst the software industry’s worst practices, and I’ll tell you why:
- Inflated Sense of Self-Worth: Code reviews have this nasty habit of spreading tips and tricks amongst your developers. When developers start systematically picking up the habits of their coworkers, they start thinking that they are worth more. The next thing you know, they are asking for raises and promotions. Well, unless you work for some gi-normous company with money coming out their ears, realistically there’s no money in the budget for those kinds of shenanigans! You hired them as a Junior Developer, and by golly they should stay that way!
- Destructive Independence: Hey, your team works because of your great leadership, and you don’t need ‘well informed’ programmers aspiring to write more complex code. When a developer gets big complicated ideas into their head, they’re likely to try and sneak it into the code, and if an idea doesn’t get your blessing it don’t go in the code, and that’s that!
- Laziness: People who want to have code reviews are really just lazy freeloaders, who are gonna wait for those around them to find their mistakes. Robbing Peter to pay Paul, anyone?!?
- Red Herrings: When developers start sharing their ideas around, some of them think they know what is going on in code they didn’t work on themselves. Y’know, if there’s a bug in Feature X, I want to talk to the developer who worked on Feature X, not some other shmoe who is familiar with the code.
- Egos: We all know that all developers are primadonna’s. What do you think is going to happen when they get their peers picking their code to pieces? Hurt feelings, that’s what. And then your job just becomes harder because of all the hugs and little reassurances you’ll have to start giving out.
- Time: Do you realize how expensive code reviews are? I don’t know about you, but I have to build the next-generation, flexible, scalable, maintainable application RIGHT NOW! I don’t have time to double the development time of a feature for a little bit of navel-gazing!
- Anti-Agile: Look, we’re all doing Agile Development, right? Agile is about being reactive to the changing requirements. Why change code when there were no changes in requirements? The other trap here is that some of the changes that come out of a code review are supposed to "make things easier for the future"… But, according to Agile, we don’t yet care about the future, we only care about getting to the end of this iteration, otherwise you are just over-engineering things.
- Self-Improvement At Your Expense: Some code review proponents say that a developer will get better from participating in a code review process. What they don’t mention is that this fictional developer may be getting better, but it’s all on your dime. If Joe-Bob the Programmer was actually interested in growing his development skills, why hasn’t he touched that $49.95 copy of "The Sun Certified Java Developer Study Book" that you had to pay for out of your already tight budget?!?
Let them Hang Themselves
Allow me, my fellow mid-level manager, to give you some advice. Let’s say that one of your developers wants you to adopt a code review process. And even though you’ve given her all the above reasons why code reviews are a bad idea (plus more, I’m sure), she insists that code reviews would be a benefit.
This is a useful tactic: Tell her to write up a 5 page proposal, with graphs and metrics for measuring the "success" of this new process relative to the cost in developer-hours and time-to-market concerns. Usually, she will stop right there, because developers hate writing proposals.
However, if she persists and actually does write the proposal, go ahead an have her present it to your boss. (Make sure to click your teeth and shake your head in pity to express your disapproval to you boss during the presentation.) 99 times out of a hundred, the code review process will die a short death, like it deserves.
Too Much Work
The previous solution I presented can work, though it is too time-consuming for us here in front-line management. So I submit another tactic that can avoid the whole mess altogether.
When your developer comes to talk to you about a code review process, look at this as an opportunity for a mini-performance-review of her work. Surely, there’s something she can improve upon herself, without having to drag down the productivity of the whole team, right? And, even if she has been excelling, more often than not she’s talked about code reviews with her co-workers, poisoning the environment around you. What with her uppity ways and deliberate efforts to undermine your authority, you’ve got a couple of ready-made performance-review topics!