Newsgroups: comp.software-eng
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!ispd-newsserver!nichols
From: nichols@ssd.kodak.com (Tim Nichols (37894))
Subject: Art vs. Engineering
Message-ID: <1991May6.165902.2116@ssd.kodak.com>
Originator: nichols@windom
Sender: news@ssd.kodak.com
Organization: Eastman Kodak
Distribution: usa
Date: Mon, 6 May 91 16:59:02 GMT

I have been interested and occasionaly amused at the blather posted
recently about whether or not software can be engineered.  Certainly it
_can_ be engineered; meatloaf _can_ be engineered, but it is subjected
to engineering only slightly less often than software {:-)}.

Engineering as a discipline refers to a rigorous process used to manage
the complexity of a solution to a given problem domain.  I recently
built a patio beside my house.  While a great deal of artistry and
construction effort went into it, there was almost no engineering
effort at all.  The problem domain was not sufficiently complex to
warrent engineering.  I was able to hold the entirety of the problem
and the intended solution in my brain at one time.

So it is with software.  Historically, software solutions were applied
to problems of relatively small complexity.  The common thread of
successful software projects was that the entirety of the program under
development was held in the brain of one or two key individuals.
Therefore, these projects required very little engineering.

Today we are faced with ever increasing complexity in the software
systems we build.  We require abstractions, models, protocols, standard
components and interfaces, etc. in order to manage that complexity.
Whether conciously or not, we are introducing and defining the
discipline of engineering software as we go.  It's a matter of
survival.

Art and Engineering are the endpoints of a continuum.  The question is
not whether building software is an art or an engineering discipline.
It is ultimately both.  The problem is that at present the engineering
half of the software continuum is vaporware.  However, it is through
the work of the engineer "wanna-be"s that the continuum will be
defined.

Once the continuum is defined, will all of the software artisans be
taken out and shot?  Of course not.  There is plenty of room for all
the traditional role players we find in other disciplines today.

Software Scientists will fill the artisans role by continually pushing
the envelope.  They will be the technology innovators.

Software Engineers will apply the state-of-the-art technology to
products and processes with precision and quality.

Software Technicians will be the hands-on support; the programmers.
The highly skilled work horses who prototype and build the dreams and
designs of the scientists and engineers.

I see no reason to expect that the evolution of the discipline of
software will differ markedly from the evolution of other technological
disciplines.  To cling to this notion of software being somehow
different from its sibling fields is sophistry.  It is a vanity
unbecoming of professionals.

And now, if you'll excuse me, I'll just step into something a little
less flammable
-- 
  Tim Nichols                                        Eastman Kodak Company
  nichols@ssd.kodak.com	                              Rochester, New York 

  "Opinions are my own, and do not reflect those of Kodak or its management"