|A vendor has asked me to write a white paper about the barriers that developers encounter in doing code reviews – particularly in regard to getting their managers to care about doing them, or how to sell the boss on adding it to the development process. (Although it’s sponsored, this is written for techies, not a commercial for the vendor… whom I won’t even mention here.)
That is: I plan to write a genuinely-useful document that you want to read all the way through. It might be titled, "7 ways to sell the boss on doing code reviews," or something akin to that.
So here’s my two questions:
• What one thing, ONE THING, do you wish the boss (or powers that be) understood about code review?
• Why did you choose THAT as the one thing to wish for?
Nobody is being quoted here. The closest I might get is to refer to someone indirectly to give the information credibility, something like, “Kim, a programmer at a Midwest insurance company, told me about about the time when….” So you can speak openly (and privately if you’re more comfortable). Though I suspect that this might spark a conversation that’d benefit everybody, so don’t be shy.
It’d help me if you included a LITTLE bit of background for yourself, so I could include that “programmer at an insurance company” attribution, should it back up the text.
Also let me know about your experience with code review. Is it something you use now, but want to improve? Something you’d like to include in your dev process? What difference would it make to get more support from Management for doing code reviews?
Incidentally, if you hate code reviews or just aren’t interested… thanks, but that doesn’t help me write this piece, which does start with the premise that code reviews are valuable. So it’s groovy with me if you don’t find them useful, but I’ll be ignoring that input for the purposes of this white paper.