Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!hsi!stpstn!cox From: cox@stpstn.UUCP (Brad Cox) Newsgroups: comp.software-eng Subject: Re: Code inspections Message-ID: <6109@stpstn.UUCP> Date: 29 Jan 91 22:06:33 GMT References: <14964@megatest.UUCP> Reply-To: cox@stpstn.UUCP (Brad Cox) Organization: Stepstone Lines: 35 In article <14964@megatest.UUCP> pat@megatest.UUCP (Patrick Powers) writes: >It seems that the problem with code inspections is largely emotional. 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. To me, the paradigm shift that we're facing is figuring out how to comprehend software products, which unlike manufactured things like firearm parts, are intangible...undetectable by the natural senses. 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. Consider two views of a stack class. The conventional view leads us to ask what language it was written in, and perhaps read the source to see what it does. I'm proposing another view from the *outside*. This view ignores the process whereby it was constructed. This involves specifying its static (does it provide methods named push and pop?) and dynamic properties (does pushing 1,2,3 cause pop to return 3,2,1?) Again, I'm not arguing against the need for a white-box view; only in favor of a belts and suspenders approach in which we also beef up our tools for capturing and reasoning about black-box information. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482