Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!pt.cs.cmu.edu!sei!rsd
From: rsd@sei.cmu.edu (Richard S D'Ippolito)
Newsgroups: comp.software-eng
Subject: Re: What exactly is a software engineer ?
Keywords: degree requirements,job definitions
Message-ID: <3359@ae.sei.cmu.edu>
Date: 15 May 89 18:39:48 GMT
References: <497@dekalb.UUCP> <40386@think.UUCP>
Reply-To: rsd@sei.cmu.edu (Richard S D'Ippolito)
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 82

In article <40386@think.UUCP> Franklin A Davis brings up certain points that
are central to the issue of software engineering.

>I'll quote a definition by Richard Fairley from "Software Engineering
>Concepts:" 
>
>    Software engineering is the technological and managerial
>    discipline concerned with systematic production and maintenance of
>    software products that are developed and modified on time and within
>    cost estimates. 

Dr. Fairley's excellent credentials aside, why is it that only software
engineering includes "on time and within cost estimates" in its definition?
Is it because those other engineering disciplines have long since
incorporated the way to do this to the extent that it is no longer
interesting to speak of it when it happens?

I suspect that the above is _not_ the case, and that only more general
statements of value were ever included in their definitions.

I can think of several products of engineering, whose complexity rivals that
of large software systems, which have been economically successful in the
commercial markets, where cost overruns would lead to company failure.


>...Fortunately the real world is often a good
>teacher, so people with CS degrees (or no degree at all) become
>proficient engineers with experience. 

I would take issue with that as a general statement, just as I would the
statement that people with no medical degrees can become good physicians by
real-world experience.  Indeed, many can become good _pracititioners_ of the
craft aspects of a trade, but few can assemble enough knowledge by mere
practice.  One of the difficulties is, that in addition to acquiring the
scientific knowledge (which I agree comes from studying Computer Science),
one must also acquire the engineering methods of systematically applying the
knowledge.  

I find it difficult to believe that one can acquire enough knowledge of a
technical field without the benefit of a formal period of study of the
field, such as you suggest, though I suppose it has been done by those rare
folks that you and I cannot hope to emulate.

The engineering methods are even less likely to learned from inspection.
One can more easily copy the products and even some of the methods of an
engineer than one can learn the thinking behind them.  As a result, those
who learn solely by inspection suffer from an inflexibility, as they cannot
adapt either the products or the methods to new situations.


>...Few CS departments devote more than a semester (if that!) to software
>engineering.  I'm not sure the undergraduate level is a good time to
>concentrate on it -- the Wang Institute required at least 2 years'
>experience, and I think that was beneficial.  

All other engineering disciplines begin at the undergraduate level.  I would
even make the case that engineering training starts before that, mostly in
ways that are not consciously seen as such.


>But, as you'll probably
>hear over and over if you continue reading this group, anyone entering
>the field should be required to have some basic knowledge of the
>engineering aspects of software product development.  Sadly, as I
>interview recent grads from excellent schools, I find this is rarely
>the case. 

I'm not sure what the "engineering aspects of software product development"
are.  Do you mean engineering design or do you mean a more general knowledge
of the _production_ aspects of software, which includes many management
issues?  Many of the production and management issues are peripheral to
generating good design, though I agree that it is helpful for the engineer
to know them.  In fact, I would claim that the design engineering should
drive the production and management, and not the other way around.


Rich
-- 
---------------------------------------------------------------------------
Ideas have consequences.                                    RSD@sei.cmu.edu
Richard Weaver
---------------------------------------------------------------------------