Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!ncar!ico!rcd From: rcd@ico.isc.com (Dick Dunn) Newsgroups: comp.software-eng Subject: Re: Code inspections Summary: reality check Message-ID: <1991Jan28.225231.19444@ico.isc.com> Date: 28 Jan 91 22:52:31 GMT References: <14964@megatest.UUCP> Organization: Interactive Systems Corporation, Boulder, CO Lines: 84 pat@megatest.UUCP (Patrick Powers) writes: ... > Though there is plenty of evidence that code inspections are cost > effective, I believe they would tend to be boring and stressful. > Boring because they are a time consuming and non-creative activity -- > current issue of IEEE Software recommends 150 lines of code reviewed > per man-day as a good figure... Well, we all know that lines of code is a lousy measure of anything except the number of newlines (don't we?:-), but still, if this measure is any- where close to real, it's a much stronger argument that Powers suggests against code inspections. A halfway-decent programmer can produce several times that 150 l/d figure...proceeding through anything at 20 lines/hour (that's 3 minutes per line, effectively???) is too slow to feel productive. > ...Stressful because it is out of the programmer's control, > and because criticism is involved. People identify closely with their > creations and find criticism painful. Criticism may be somewhat painful inherently, but again I'm going to speak about a "halfway-decent programmer" and say that such a person has long ago transcended deriving personal injury from criticism of the code. Good grief, the *compiler* picks your code apart early on. There are enough opportunities to confront one's human frailty and fallibility in a day of programming that I don't think this holds water. Sure, there are prima donnas and cowboy kids in the programming world, but they're not in the mainstream. Train 'em to accept criticism or get rid of 'em! In my experience, when I hear a programmer (of the type I know/respect and have been around for years) who's looking at code say something like "That's idiotic! That's absurd! There's no way in hell that could possibly work, you bozo!" - it's 95% certain he's talking about his own code. > Not only that, but your average programmer was very likely attracted to > programming in order to avoid social interaction and to create > something under his/her personal control without anyone else watching. This is a fun thing when we joke about it, but it's pretty crappy to pretend that it's serious. I think the average programmer was attracted to programming either because of the $ or because programming is fun/inter- esting. Sometimes, long stints at the terminal leave you without much social interaction for a while, so it's at least plausible to hypothesize that "the average programmer" can handle a low level of social interaction. That doesn't mean it's sought out. Don't confuse correlation with causality. > He/she is likely to be on the low end of the social tact scale and > singularly unqualified to deal with this delicate situation... If you've got a bunch of low-tact people, the situation isn't delicate! > In order to reduce these problems the following has been suggested: > 1) The author not be present at the inspection That means any minor question will have to be transcribed instead of being answered on the spot. It eliminates useful feedback. Also, if you've got the class of delicate egotists you've described, it means the author will be fretting about what people are saying about his precious code behind his back. > 2) Only errors are communicated to the author. No criticism of style allowed. Huh? I don't want to put words in your mouth, but this sounds like either style isn't important enough to criticize, or at the least, that style takes a back seat to coddling the egos. > I've toyed with the idea of instituting code inspections but just > couldn't bear to be the instrument of a good deal of unhappiness... Instead of "instituting" them, why not simply allow them to happen. As you note later in the article, there are some cases where going over particular code is a Very Good Idea, and other cases where it's Massively Boring and Useless. So let people figure out when they need to go over the code, and at what level. (Sometimes you want to go over the high-level--the data structures, the general breakout. Once in a while you really want to go over each line of a small section in excruciating detail.) Think of it this way: Code inspection is a tool. You don't use every tool for every job. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...Mr. Natural says, "Use the right tool for the job."