Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!uwm.edu!linac!att!cbnews!cbnewsm!lfd From: lfd@cbnewsm.att.com (leland.f.derbenwick) Newsgroups: comp.software-eng Subject: Re: Code inspections Summary: judge not, lest you mess up the effectiveness Keywords: inspection, software engineering Message-ID: <1991Jan29.230431.5918@cbnewsm.att.com> Date: 29 Jan 91 23:04:31 GMT References: <14964@megatest.UUCP> <40530@genrad.UUCP> <7362@tekchips.LABS.TEK.COM> Organization: AT&T Bell Laboratories Lines: 38 In article <7362@tekchips.LABS.TEK.COM>, rjn@crl.labs.tek.com writes: > In article <40530@genrad.UUCP>, mas@genrad.com (Mark A. Swanson) writes: > > In practice we have not found programmer's egos to be a major problem > > to properly conducted Code Inspections. This, of course, assumes that > > the Inspection process is actually following the defined cookbook approach, > > complete with moderator who keeps the discussion on track and non personal > > and a seperate reader who actually goes through the code (or design document: > > Inspections work well for them as well) one piece at a time. In addition, it > > is absolutely forbidden for someone's manager to help inspect his product or > > to use the # of defects found by an inspection as part of performance rating. > > > > I just don't see this as being realistic. What other job where a product > (software in this case) is produced do you find people not being judged on > the quality of their output? People absolutely have to be judged on how well > they perform their jobs and if putting out high quality software is their > job then their manager should be able to measure their job performance and > react accordingly. It depends what you see as the output. In my view, that's the code that makes it past inspection, integration, and test, and goes out to the customer. A higher-than-average rate of errors found in inspection might mean that the programmer is bad, or it might mean that he/she writes code that is so clearly readable that the inspection catches a greater than average percentage of the errors. Similarly, a higher-than-average rate of errors caught in integration and test might mean that the code is bad, or the inspection was sloppy, or that the code was designed to be thoroughly testable. If you make errors caught at an early stage "evil", then people will do everything they can to avoid catching them there: writing unclear code, avoiding inspections, forcing inspections to be rushed, arguing over what is and isn't a bug, etc., etc. And you might as well not bother doing the inspections at all. -- Speaking strictly for myself, -- Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ -- lfd@cbnewsm.ATT.COM or !att!cbnewsm!lfd