Path: utzoo!mnetor!uunet!husc6!cmcl2!beta!unm-la!claborn
From: claborn@unm-la.UUCP (Joe Claborn)
Newsgroups: comp.software-eng
Subject: It IS Engineering
Message-ID: <691@unm-la.UUCP>
Date: 9 Feb 88 01:21:49 GMT
References: <6879@agate.BERKELEY.EDU> <4618@teddy.UUCP>
Reply-To: claborn@unm-la.UUCP (Joe Claborn)
Organization: Univ. of New Mexico at Los Alamos
Lines: 31
Keywords: Art Engineering Tolerances

In article <4618@teddy.UUCP> svb@teddy.UUCP (Stephen V. Boyle) writes:
>In article <6879@agate.BERKELEY.EDU> bks@ALFA.berkeley.edu (Brad Sherman) writes:
>>current software development is not really "engineering."
>>
>>What do "real" engineers do that we do not?
>>
>
>Since my background is Chemical Engineering, I'll use examples from that field.
>
>In Chem. E., when I needed to design a heat exchanger, I used a set of refer-
    (* deleted stuff about how easy it is to design heat exchangers *)
>... !{decvax,linus,wjh12,mit-eddie,masscomp}!genrad!svb
>Steve Boyle  
>GenRad Inc,  Production Test Division
>MS 06, 300 Baker Ave, Concord, Mass.  01742

I thought that engineering was choosing the best solution (given constraints)
from the solution space. Perhaps that when designing heat exchangers the
engineering is ALREADY done and can be looked up in a table. For a lot of
software that isn't the case. I define best solution as the solution that
minimizes the following costs.
   --> cost of implementing
   --> cost of maintenance
   --> cost of modifying

The best software to a solve a specific problem may be a piece of 'canned'
software or it may be developed 'in-house'. In either case if there
is not engineering involved in the decision then the solution won't be
'best'. 

(* save bandwidth - delete your signature *)