Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!know!slug!wex From: wex@dali.pws.bull.com (Der Grouch) Newsgroups: comp.software-eng Subject: Re: Code inspections Message-ID: Date: 1 Feb 91 17:17:32 GMT References: <14964@megatest.UUCP> <6109@stpstn.UUCP> Sender: news@pws.bull.com Organization: Bull Worldwide Information Systems Inc. Lines: 29 Nntp-Posting-Host: dali.pws.bull.com In-reply-to: cox@stpstn.UUCP's message of 29 Jan 91 22:06:33 GMT In article <6109@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: While not in any way arguing against your point, or about the utility of code inspections in general, isn't it about time that we started breaking our enfatuation with the *process* of building software (source code, style rules, programming language, lifecycle, methodology, software development process, CASE, etc, etc) and started concentrating on the *product* itself. Well, I'm not sure I totally understand your statement. To me, every product is the end result of a process. In particular, if we are going to use tools of some sort, we are going to thereby impose a process on the tool users. For example, you say... I envision tools to assist in understanding the static and dynamic properties of a piece of code the way physicists study the universe, not by asking how it was built (a process question), but by putting it under test to determine what it does. This paragraph, to me, seems to be advocating one kind of process over another. I'm not saying that you're right or wrong in advocating the "test and see what it does" process, but I am saying that it's a process like any other. Have I missed your point entirely? -- --Alan Wexelblat phone: (508)294-7485 Bull Worldwide Information Systems internet: wex@pws.bull.com "Honesty pays, but it doesn't seem to pay enough to suit some people."