Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!ginosko!infinet!adelie!ccavax!merriman
From: merriman@ccavax.camb.com (George Merriman -- CCA/NY)
Newsgroups: comp.software-eng
Subject: Re: What exactly is a software engineer ?
Message-ID: <292@ccavax.camb.com>
Date: 11 Jun 89 15:28:30 GMT
References: <3359@ae.sei.cmu.edu> <5004@goofy.megatest.UUCP> <CLINE.89May24173256@sunshine.ece.clarkson.edu> <3444@ae.sei.cmu.edu>
Organization: Cambridge Computer Associates, Inc.
Lines: 46

An interesting article on this general subject appears in _Open Channel_ 
department of the May, 1989 issue of the IEEE _Computer_ magazine. 
It is by Robert L. Baber, who describes himself as a practicing
"software developer of long standing" and as an "engineer (electrical)
by education." 

He argues that the term "Software Engineering", as it is commonly used today,
describes what is really a management activity rather than an engineering
activity and suggests that we start using another term so as to not confuse it
with what software engineering ought really to be. He suggests the term
"Integrated Software Life Cycle Management (ISLCM)" as suitably impressive to
satisfy our desire for pomposity.

He describes what he terms engineering as:

	"The application of scientific knowledge and principles to the
	task of designing and constructing a device, machine, or system
	of economic value . . . Especially noteworthy is that the
	engineer employs a scientific, theoretical foundation to
	verify -- by systematic calculation and before the object is
	actually built -- that a proposed design will satisfy the
	specifications."

Though I am not an engineer, I've had occasion to work in several "engineering
departments", so to speak, and find this article fits with my experience. I
think it is important to keep in mind that someone employed as an engineer is
often called upon to be a manager and designer as well as an engineer and the
"get the project out on schedule and under budget" aspect of the job  is
clearly part of the management side of the job. For example, in construction
work project management is often handled by non-engineers (the contractor's
staff) and while an engineer is called upon to verify that a design (by an
architect) will not fall down and meets code, he may never even visit the site
or see a schedule.

So if "Software Engineering" isn't really software engineering, what is? I have
yet to see a software shop where anything comparable to the "systematic
calculation" mentioned in the article goes on (if you don't believe me, go
watch a consulting structural engineer at work), and I think it will be a while
before a true software engineering discipline is practiced on a wide scale in
this industry, at least my part of it. When it happens I think it will be based
on the sort of rigorous proof-of-correctness and algorithm performance analysis
taught and developed in the more mathematically inclined CS departments. The
trouble is, I think the theory needs to be distilled down to something we
ordinary mortals can handle before it will be usefull. We need our own Oliver
Heavyside.