Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!motcid!kutem From: kutem@rtsg.mot.com (Jon Kutemeier) Newsgroups: comp.software-eng Subject: Re: Code inspections Message-ID: <4597@berry12.UUCP> Date: 29 Jan 91 17:09:44 GMT References: <14964@megatest.UUCP> <40530@genrad.UUCP> Sender: kutem@motcid.UUCP Organization: Motorola Inc., Cellular Infrastructure Division Lines: 95 In-reply-to: rjn@crl.labs.tek.com's message of 28 Jan 91 23:10:17 GMT Distribution: In article <7362@tekchips.LABS.TEK.COM> rjn@crl.labs.tek.com writes: Path: motcid!uunet!zephyr.ens.tek.com!tekchips!snowbird!rjn From: rjn@crl.labs.tek.com Newsgroups: comp.software-eng Keywords: inspection, software engineering Date: 28 Jan 91 23:10:17 GMT References: <14964@megatest.UUCP> <40530@genrad.UUCP> Sender: news@tekchips.LABS.TEK.COM Reply-To: rjn@crl.labs.tek.com (Jim Nusbaum) Lines: 56 In article <14964@megatest.UUCP>, pat@megatest.UUCP (Patrick Powers) writes: >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. Again, >this may very well have attracted them to programming: it doesn't >matter whether anyone likes their personality, all that counts is >whether the program works. I think this is really ridiculous. Pigeonholing the "average" programmer as some unprofessional, nerd-dweeb is a little out there. If a person is unable to perform professionally because of social/emotional problems then perhaps they are in the wrong profession. I don't think this describes today's "average" programmer at all. I tend to agree. 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. I find the attitude expressed in the above two postings very disturbing. They seem to imply that people involved in software production somehow need to be treated very differently from people involved in other types of production. You aren't allowed to measure their work, you can't judge their work, you can't evaluate their job performance based on their work. This kind of thinking is what is keeping software from becoming a true engineering discipline and it is why so much software is so bad. Programmers need to realize that their job is producing high quality software, not just a program that "works". They need to be held accountable for their work. I have found that true professionals don't mind code inspections and walkthroughs, because they are confident in their ability and proud of their work. Unfortunately, this a problem. Since the coding of software can take many different forms, how do you judge "quality"? What one person perceives as a higher "quality" of code may seem like a lower "quality" of code to another. Right now, there is no one correct way to write a program, unlike other engineering diciplines, which may have a single answer (Does this bridge support X lbs of weight? A simplified example...). How to define quality for software is still nebulous right now. Do you base it on how well the program works? How efficiently it runs? How well it is commented? All the above? Quality will mean different things to different people, depending upon what their needs are. That is why there is concern over rating programmers based on the "quality" of their code. Disclaimer: This is my opinion only. Tektronix may not share my opinion. Jim Nusbaum, Computer Research Lab, Tektronix, Inc. [ucbvax,decvax,allegra,uw-beaver,hplabs]!tektronix!crl!rjn rjn@crl.labs.tek.com (503) 627-4612 Jon Kutemeier__________________________________________________________________ -----------------Software Engineer /XX\/XX\ phone:(708) 632-5433 Motorola Inc. Radio Telephone Systems Group ///\XX/\\\ fax: (708) 632-4430 1501 W. Shure Drive, Arlington Heights, IL 60004 uucp: !uunet!motcid!kutemj -- Jon Kutemeier___________________________________________________________________ ------------------Software Engineer /XX\/XX\ phone:(708) 632-5433 Motorola Inc. Radio Telephone Systems Group ///\XX/\\\ fax: (708) 632-4430 1501 W. Shure Drive, Arlington Heights, IL 60004 uucp: !uunet!motcid!kutemj