Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!dimacs.rutgers.edu!mips!wdl1.wdl.loral.com!spl27!pcg
From: pcg@spl27.spl.loral.com (Paul C George)
Newsgroups: comp.software-eng
Subject: Re: the scientist and the engineer
Message-ID: <1991Jan30.000631.2017@wdl1.wdl.loral.com>
Date: 30 Jan 91 00:06:31 GMT
References: <1991Jan26.210023.28534@cbnewsh.att.com> <1991Jan27.234614.2327@cbnewsc.att.com> <1991Jan28.125444.71@skyler.mavd.honeywell.com>
Sender: root@wdl1.wdl.loral.com (SUPER USER)
Reply-To: pcg@spl27.spl.loral.com (Paul C George)
Distribution: na
Organization: Loral Software Productivity Laboratory
Lines: 44
Nntp-Posting-Host: spl27

In article <1991Jan28.125444.71@skyler.mavd.honeywell.com>, djbailey@skyler.mavd.honeywell.com writes:

|> There is an interesting analogy in "Wicked Problems, Righteous 
|> Solutions" by Peter DeGrace and Leslie Hulet Stahl comparing software
|> developers to the craftsmen who built cathedrals in the Middle Ages.
|> 
|> Like the craftsmen, we have a lot of practical techniques and "rules
|> of thumb" to help us build but we don't have the scientific background 
|> to understand why it works and how to make it work consistantly.
|> ......
|> One of the points made in this book and other places is that software 
|> development takes place in the mind and the mind is unexplored 
|> territory. If we can teach people to become expert problem solvers, 
|> then we will have developed the scientific background we need for 
|> software development.
|> 
|> -- Don J. Bailey


At the risk of being flippant, I am reminded of a comment by Sam Redwine
at the 1988 Software Process Workshop, which won the best line award:

       Software and Cathedrals are much the same -
       First we build them, then we pray.

If we ever actually use an engineering process where we specify, design, implement
and verify software, perhaps we can get beyond this. Current bidding & scheduling
practices make it so we rarely actually design software. Thought is regarded as
a non-productive activity, as it is hard to judge the quantity & quality of 
output. Creating lines of code or numbers of modules (even incorrect or useless 
ones) are easy to measure and give the illusion of progress.

The current software engineering process seems to be:

1) market, 
2) take a cursury look at the problem & possible solution (requirements analysis
   & Design)
3) wave hands & philosophise, smoke & mirrors optional (customer requirements & 
   design reviews), 
4) implement as as the spirit moves based upon individual understanding, 
5) find out what you built ('integration testing'), 
6) fix until it works, 
7) determine functionality (FQT),
8) modify reqirements to reflect the product and/or repeat step 6.