[comp.software-eng] It IS Engineering

claborn@unm-la.UUCP (Joe Claborn) (02/09/88)

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 *)

raveling@vaxa.isi.edu (Paul Raveling) (02/10/88)

In article <691@unm-la.UUCP> claborn@unm-la.UUCP (Joe Claborn) writes:
>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?
>> ...
>
>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
>

	There's a heavy component of art in much software development,
	sometimes for better, sometimes for worse.  This is especially
	true for developing software without a well-defined (detailed)
	functional specification.  Some examples from my own experience...

		EPOS	(PDP-11 operating system, ISI, 1975++),
		GenRad/FutureData Slave Emulator product line, 1969++

			Perhaps 50% art and inspiration, 50%
			production by engineering discipline.


		B1-B Central Air Data Computer, Standard Central
		Air Data Computer, ~1984

			99% engineering discipline
	

	It seems to me that the most innovative work of lasting
	value involves a lot of art.  However, not may people
	can say "Fund me; I'll create a masterpiece!"  and be
	taken seriously.


---------------------
Paul Raveling
Raveling@vaxa.isi.edu

mjl@ritcv.UUCP (Mike Lutz) (02/12/88)

In article <4741@venera.isi.edu> raveling@vaxa.isi.edu (Paul Raveling) writes:
>
>	There's a heavy component of art in much software development,
>	sometimes for better, sometimes for worse.  This is especially
>	true for developing software without a well-defined (detailed)
>	functional specification.  Some examples from my own experience...
>

Anyone who has worked with a really good electrical or mechanical engineer
knows that there is every bit as much room for creativity, elegance, and
art in those domains as in software development.  However, it does seem that
one can make a decent living as an E.E. by remembering a bunch of formulas
from Circuits III (or, better yet, the page in the CRC reference books where
the formulas can be found).  The current state of software development is such
that such canned solutions are rare, so an even higher premium must be placed
on native design talent.

Good God! I said something nice about hardware types!

Mike Lutz
Rochester Institute of Technology
rochester!ritcv!mjl
-- 
Mike Lutz	Rochester Institute of Technology, Rochester NY
UUCP:		{allegra,seismo}!rochester!ritcv!mjl
CSNET:		mjl%rit@csnet-relay.ARPA