The Old Joel on Software Forum: Part 4 (of 5)

Software Inspections

do anyone have any experience with software inspections? is this practice wide spread?
i dun seem to see much reference to software inspections which all the emphasis on XP and TDD nowadays, which i find it strange since there are reports and studies showing the effectiveness of software inspections.

any comments?

new_one
Thursday, May 20, 2004

Pair programming is all about software inspections.

check the date
Thursday, May 20, 2004

Is this another term for 'code review', or are you talking about something different?

Edward
Thursday, May 20, 2004

Software Inspections are much more formal than code reviews. They usually involve about 5 people which includes the author, a mediator, a recorder, and several inspectors. They where invented by IBM and have been proven in many studies to reduce the overall cost of software projects by finding a significant amount of errors.

Was there anything else you wanted to know about them?

Craig H
Thursday, May 20, 2004

We've started doing code reviews, and I'm honestly up in the air about the effectiveness. We've taken a rigorous approach which I think is sometimes counterproductive.

The idea of statically looking at code seems strange to me. I think you only get a good understanding of code by running it. Yes you can do that with code reviews, but it is secondary to reading the code.

Since the reviewers don't really understand the code it is easy to turn code reviews into a stylistic arguement. I think it is important to note that there is a difference between code that doesn't work properly and code that isn't indented they way you like or is using an exception when you'd prefer assert.

christopher baus (www.baus.net)
Thursday, May 20, 2004

actually, i am curious why this practice doesnt seem to be more common in most software house? am i right or just that i am just not in the right company?

new_one
Thursday, May 20, 2004

It's fairly standard in CMM and ISO 9000 companies... similar to a Formal Qualifications Test but done at regular intervals.

Ron
Thursday, May 20, 2004

Code reviews add value, such as locating bugs, improving readibility, sharing programming techniques, and spreading knowledge about what the code structure.

However, each code review requires several hours of total effort to read the code in advance and hold a code review meeting. I'm not convinced that they're worth it.

Julian
Friday, May 21, 2004

Christopher wrote:

"he idea of statically looking at code seems strange to me. I think you only get a good understanding of code by running it. "

I do not agree with you. I have been running Windows for years and this should have provided me with lots of insight into the source code. I can assure you that is not the case.

Code reviews, software inspection, program walkthroughs, whatever you call them can be quite useful. To prevent bickering about stylistic details (the curly brace on the next line, the number of spaces for indentation), any serious team should run a stylechecker that automatically flags any errors in the naming and style departement.

Not knowing what the code is supposed to do makes for better reviews, IMHO, since for the reviewertro understand the intention by just reading the code ( a major goal, again IMHO), the coder is forced to produce expressive code.

Code reviews should be done as a team so everyone can learn from what is being found.

Say cheese
Friday, May 21, 2004

To some degree, even "stylistic arguments" are useful.

If people use a basically common style, it makes it a bit easier to have more than one person make changes to it.

One way to avoid petty stylistic arguments is to run every thing through a formatter (set up in one way).

I have found significant benefit to code reviews in my shop. Code reviews of new people is helpful in correcting problems and inconsistencies early. Also, having people used to the idea that other people look at the code routinely avoids the "this is my code. No one can look at it" problem. That is, it fosters the sense that the group, rather than the individual, owns the code.

njkayaker
Friday, May 21, 2004

>
"he idea of statically looking at code seems strange to me. I think you only get a good understanding of code by running it."

I meant running the code say from a debugger. You can get immediate feed back on what the code is doing. If you see a path that isn't reached in the debugger you can note that and try to determine a scheme to reach that path.

christopher baus (www.baus.net)
Friday, May 21, 2004

> You can get immediate feed back on what the code is doing.

The code says what is doing, doesn't it?

anoymous
Friday, May 21, 2004