Re: Why Create Coding Standards and Perform Code Reviews?

[johnwashburn]

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:

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.

[johnwashburn]

I am in QA now (about 15 years), but I was an application and driver developer for 12 years prior to that. I still develop code. I just don't do it to put food on the table. I was/am all five of the developers below.

I have noticed there are 5 classes of developers and the quality of their work depends on how they self-defined their job.
1. I write code
2. I write code that compiles
3. I write code that compiles and works
4. I write code that compiles and works well
5. I write code that compiles and works well for a long time
The developer with 1/50 the defect density of his peers clearly wrote code that compiled and worked well for a long time.

I also told his manager that the developer was slow only because of manager's incorrect definition of done. The manager was using The programmers says so; i.e. has submitted some pastiche of code for peer review. as the measure of done. I pointed out that if done is defined as passing a peer code review with no correction noted (regardless of the need for re-review), then most of his developers have never completed their task and the guy we were discussing was done a over half the time. Suddenly, his careful, professional craftsmanship did not look so slow.

Code review helps every developer and designer become a careful, professional craftsman at developing or designing software that compiles and will work well for a long time. Code review helps every developer and designer become the careful, professional craftsman they long to be. Code review are for the long view.

Any competent carpenter can produce a china cabinet in a day, but the guy who takes 15-20% longer, makes a cabinet which will be on the Antiques Roadshow 50 years from now.