Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!kodak!ispd-newsserver!uucp From: amusing!lordbah@bisco.kodak.COM (Lord Bah) Newsgroups: comp.software-eng Subject: Code inspections Message-ID: <9101300449.AA01073@bisco.kodak.COM> Date: 28 Jan 91 23:52:37 GMT Sender: news@ssd.kodak.com Reply-To: amusing!lordbah@bisco.kodak.COM Followup-To: comp.software-eng Organization: Eastman Kodak Lines: 53 Originator: uucp@bisco Return-Path: On the last project I worked on we held code inspections at each implementation milestone. While they did get boring on occasion we didn't find them particularly stressful. As they say, it's the code that's being inspected, not the coder. I don't have any numbers, but the project had about two orders of magnitude fewer problems reported during QA. > 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. There were between 5 and 7 of us over the course of development. The inspections lasted about 4 hours and covered in the neighborhood of 1000 lines of code each. We found it ABSOLUTELY ESSENTIAL that each person participating receive a copy of the code a few days before the inspection and go through it on their own before the inspection, otherwise massive time gets wasted as people read the code during the inspection and there are fewer useful contributions because people don't have any understanding of the code. On the average call it 1 day of work for each person, or about 166 lines of code per man-day (not bad, IEEE!). > 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. > He/she is likely to be on the low end of the social tact scale and > singularly unqualified to deal with this delicate situation. An interesting insight. Not always true, of course, and often countered by the drive to "show-off" in those who consider themselves clever. > In order to reduce these problems the following has been suggested: > 1) The author not be present at the inspection > 2) Only errors are communicated to the author. No criticism of style > allowed. BAH! I must disagree with both of these. The author must be present to provide explanations when called for, and to note what the inspection requires to be corrected. Style issues are also fair game. Note that having a group coding standard helps immensely in preventing religious wars during the code inspections (they basically get moved to the time when you determine the coding standard). You can then focus on proper functionality, maintainability, adherence to standards, etc. We found code inspections productive and useful without inducing unnecessary stress. -------------------------------------------------------------------- Jeff Van Epps amusing!lordbah@bisco.kodak.com lordbah@cup.portal.com sun!portal!cup.portal.com!lordbah