in reply to Why Create Coding Standards and Perform Code Reviews?
RE: Of course, code reviews are not free and there is an opportunity cost in that time spent reviewing code means less time spent on other activities.
I think you need more here. Which activities could you spend time on (slinging code, taking tech support calls, doing in-field programming, working on design reviews, etc.)? Which activities are reduced by code reviews (fewer tech support calls, less in field programming, less patching, less PR spin to explain crappy performance, avoiding patch Tuesday, etc.) Which activities are slowed by code reviews and design reviews (design reviews delay the on-set of coding, programmers complain that reviewing code draws them from their core tasks, etc.)? All of these cost/save money.
Code review only pays if you take the long view (as you do) and you show the savings in maintenance costs offsets the increase cost for initial development.
As a QA guy I use this example from my past.
I worked at a company with about 120 developers. I saw all five kinds of developers (see below).
One was always dinged as being "slow". He would deliver his initial code at a rate of about 15% behind nearly all of his peers. None the less was trusted and seen as an excellent developer. During a review he was as to speed up and his response was that quality would suffer; which is how I got pulled into this as a personnel matter. (BTW using QA people and QA metrics for developer personnel reviews is STUPID. If you as a manager did not know the information below, then you should not be a manager. </rant>)
What we in the QA department noticed and could demonstrate was that his code almost NEVER went back for re-write. We had defect records and support call records going back three to five years (depending on the module). Almost never is defined as just a bit more than 1/50th of the defect density rate of his peers. Where is peers averaged 100-105 defects per 1000 function points. He introduced 2 or 3 for the same measure of code size. His unit testing and personal code review style was off the charts phenomenal. When he said the code was done, it was done. We had implemented Fagan reviews, but he had internalize the principles nearly a decade before.
Over beer, I asked on this and his answer was:
Hopefully there is someting in the above you can use.
I think you need more here. Which activities could you spend time on (slinging code, taking tech support calls, doing in-field programming, working on design reviews, etc.)? Which activities are reduced by code reviews (fewer tech support calls, less in field programming, less patching, less PR spin to explain crappy performance, avoiding patch Tuesday, etc.) Which activities are slowed by code reviews and design reviews (design reviews delay the on-set of coding, programmers complain that reviewing code draws them from their core tasks, etc.)? All of these cost/save money.
Code review only pays if you take the long view (as you do) and you show the savings in maintenance costs offsets the increase cost for initial development.
As a QA guy I use this example from my past.
I worked at a company with about 120 developers. I saw all five kinds of developers (see below).
One was always dinged as being "slow". He would deliver his initial code at a rate of about 15% behind nearly all of his peers. None the less was trusted and seen as an excellent developer. During a review he was as to speed up and his response was that quality would suffer; which is how I got pulled into this as a personnel matter. (BTW using QA people and QA metrics for developer personnel reviews is STUPID. If you as a manager did not know the information below, then you should not be a manager. </rant>)
What we in the QA department noticed and could demonstrate was that his code almost NEVER went back for re-write. We had defect records and support call records going back three to five years (depending on the module). Almost never is defined as just a bit more than 1/50th of the defect density rate of his peers. Where is peers averaged 100-105 defects per 1000 function points. He introduced 2 or 3 for the same measure of code size. His unit testing and personal code review style was off the charts phenomenal. When he said the code was done, it was done. We had implemented Fagan reviews, but he had internalize the principles nearly a decade before.
Over beer, I asked on this and his answer was:
I didn't become a good developer until I had to maintain my own code over the course of four years. Suddenly, I could not use the rationalization: 'if I had been the developer, then I would not have make that mistake or overlooked that possibility.’My take away was we all make mistakes. The best of us though understand this and plan for ways in which those mistakes will not leave our desk, leak much further than our peers or, at the least, never leave the company walls. Even master welders subject their welds to X-ray and other inspections because a few cold welds in the wrong place can undermine the whole steel structure. Also it is better for your welding buddy to find the cold weld, than your foreman. Better the foreman catch the cold weld than the city inspector.
Hopefully there is someting in the above you can use.
In Section
Meditations