Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pdn!reggie From: reggie@paradyne.com (George W. Leach) Newsgroups: comp.software-eng Subject: Perspective Views? (was Re: Code inspections) Message-ID: <1991Jan30.205647.16511@pdn.paradyne.com> Date: 30 Jan 91 20:56:47 GMT References: <14964@megatest.UUCP> <6109@stpstn.UUCP> Sender: news@pdn.paradyne.com (News Subsystem) Organization: AT&T Suncoast Division, Largo FL Lines: 40 Nntp-Posting-Host: dinsdale 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. I think the reason we can't break away from this type of thinking is that many organizations sorely need to concern themselves with improving these processes. The current mode of operation is not sufficient. >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. We need this as well, if for no other reason to aid in the learning phase for new programmers who will take on maintenance responsibilities. >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. One thing that has always bothered me about topics like this is the fact that software is not a natural phenomenon, but a man(person)-made commodity. As such we should strive for understanding what we are building (or growing, if you believe Harlan Mills) before we do so. Imagine if a Civil Engineer built a bridge and then tried to understand its structure or what it does :-) Certainly software is very different from any other type of engineering or product development activity, but we need to have a way to model the behavior of the system before we build it ala simulation or some other technique to gain insight into the operations before we commit it to code. -- George W. Leach AT&T Paradyne reggie@paradyne.com Mail stop LG-133 Phone: 1-813-530-2376 P.O. Box 2826 FAX: 1-813-530-8224 Largo, FL 34649-2826 USA