Does your development team do code review? Or do you wish you could? I’ve a few questions and would like your input.
-
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.
-
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.
I find that code reviews are a vital part of the SDLC. Having another developer review your code is incredibly useful. Developers are human beings, and as such, we can make mistakes or require room for improvement in the work we perform. How many times have you looked at some code and thought "Why did they implement it that way when this way is more more efficient / elegant / conforming to coding stadards" (select as appropriate). Here's a useful article on what to look for in a code review[^] If you are introducing code reviews, then you need to ensure that includes everyone - yes even the senior developers who perform code reviews need to have their code reviewed too. Code reviews increase code quality and ensure coding standards are maintained to name just a few of their benefits. My biggest question however is why are you having to justify their use in the first place? Anyone who has worked as a software developer in a professional capacity will understand and appreciate their benefits without requiring any persuasion.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
-
I find that code reviews are a vital part of the SDLC. Having another developer review your code is incredibly useful. Developers are human beings, and as such, we can make mistakes or require room for improvement in the work we perform. How many times have you looked at some code and thought "Why did they implement it that way when this way is more more efficient / elegant / conforming to coding stadards" (select as appropriate). Here's a useful article on what to look for in a code review[^] If you are introducing code reviews, then you need to ensure that includes everyone - yes even the senior developers who perform code reviews need to have their code reviewed too. Code reviews increase code quality and ensure coding standards are maintained to name just a few of their benefits. My biggest question however is why are you having to justify their use in the first place? Anyone who has worked as a software developer in a professional capacity will understand and appreciate their benefits without requiring any persuasion.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
I don't need to be sold on the value of code reviews... and I like to think that the developer reading the white paper knows the benefits, too. (Plus, I've written a few articles on the topic, myself.)
My biggest question however is why are you having to justify their use in the first place? Anyone who has worked as a software developer in a professional capacity will understand and appreciate their benefits without requiring any persuasion.
Alas, some people work in environments where the boss had one idea of "the right way to do things" and the developers have a different perception. Sometimes, you need ammunition to change the boss' mind: the benefits as the manager sees them, not the worker-bee. And that's what I aim to write.
-
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.
eschindler wrote:
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 why not just google some studies and argue from the point of cost effectiveness? Might note as well that code reviews or any process control measures for that matter are not effective unless management actively supports and enforces it.
-
eschindler wrote:
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 why not just google some studies and argue from the point of cost effectiveness? Might note as well that code reviews or any process control measures for that matter are not effective unless management actively supports and enforces it.
Of course I can look at studies. Heck, I've authored a few of those research reports! But I would far rather hear from individuals who can explain the situations from their own perspective. There's a vast difference in reading, "Twenty percent indicated that they wanted their manager's support," and "I once had a manager whose refusal to listen brought me to tears, when he...." I can include data from the research reports without asking for assistance. I've been using search engines since Gopher and Archie were newfangled Internet tools. ...But for the human experience? I need people.
-
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.
Background - old(ish) grumpy git who worked in UK Financial Services for far too long. Bolshie, argumentative, pretty good at what I did, didn't entirely trust my peer group. Scenario - "forced" into "SDLC" (yeah, they named their internal process that :sigh:)... we all knew what it should be, shame the committee defining the (compulsory) process didn't. It was a disaster waiting to happen, oops, it didn't wait, it happened. Opportunity - "Volunteers required for training on Peer Review (and how to do it properly)". Me - I'll go for that ... in the back of my mind was sarcasm, mickey-take, etc. Fact - Training was bl***y good - Takeaway from that = make sure the training is good. Me - actually this can work, I need to evangelize (exaggerating only a little) ... Takeaway = if the training is good, the grumpy git will get the rest on board
eschindler wrote:
What one thing, ONE THING, do you wish the boss (or powers that be) understood about code review?
It's not about blame, putting people down, nit-picking. Ok, not "ONE THING" ... rethink ..
Chill60 says:
It's not there to find faults, it's there to add QUALITY
eschindler wrote:
Why did you choose THAT as the one thing to wish for?
I guess because in my experiences of the "powers that be", it always boils down to someone (else) to blame instead of focussing on making the process better. The thing I absolutely LOVED about the training process was the insistence that it needed to be completely objective. There were processes put in place to ensure that objectiveness... including timed meetings. All designed to stop anyone being put on the defensive to be honest. I was told at one point to print out the "document" I was reviewing (it's not just about code) and go "find a palm tree". Ok, it was a spindly little tree next to the smoking shelter, but it worked - get away from distractions (Or ... treat the review with respect!)
eschindler wrote:
Nobody is being quoted here.
Feel free to include a link to this post (I did say I was a bolshie, grumpy, old git!) If you need more, just let me know. Can't mention any company names obviously. Or you could quote me as a "convert to code review"
-
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.
We had an Senior Ex-Colleague who came monthly/weekly for support and code review on the First firm I worked.I think it is essential for good software/project to have code reviews if not possible by outside person even peer reviews.So that we can find something useful that the reviewer think good.Also a good opportunity for the developer to learn about strength/weakness on coding.
LK
