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: Re: Art vs. Engineering
Message-ID: <1991May9.124559.2924@ssd.kodak.com>
Sender: news@ssd.kodak.com
Organization: Eastman Kodak
References: <1991May6.165902.2116@ssd.kodak.com> <35177@athertn.Atherton.COM>
Distribution: usa
Date: Thu, 9 May 91 12:45:59 GMT

In article <35177@athertn.Atherton.COM> mcgregor@hemlock.Atherton.COM (Scott McGregor) writes:
>In article <1991May6.165902.2116@ssd.kodak.com>, nichols@ssd.kodak.com
>(Tim Nichols (37894)) writes:
>...(many good comments)...
>
>> 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.
>
>I don't know if I disagree or not, but I am not quite so certain as you that
>Software as a technological discipline will wind up looking more like
>traditional engineering.  At least one other possible path seems possible.
>At the end of the last century, filmaking was a very technical discipline.
>...(stuff deleted)...
>There are many kinds of software, and it may well be that different
>parts of it go different ways.  I could easily see systems that support
>analytical chemistry instruments, or systems that calculate trajectories
>going in the
>direction you describe, and at the same time, I can see systems aimed at
>increasing the capabilities of the average office worker to remember, to
>coordinate with others, etc. going the filmaking direction.
> ...(more stuff deleted)...
>Scott McGregor
>mcgregor@atherton.com


You make a valid point, but I contend that filmmaking is the wrong analogy to 
apply.  Films largely try to educate and/or entertain.  The vast majority of
software does not (excepting video games and the like).  A good film should
be memorable; good software should not even be noticed. (someone stated this
in an earlier thread, but I can't remember who)

Given that the vast bulk of software we build and use is dedicated to helping 
us work smarter and faster, to have it be memorable would be cumbersome.

I contend that a better anaology would be the role of a building architect.
A building architect is aware of the technical aspects of construction, but 
his design effort is focused on how people interact with the building.  In a
similar vein, the software architect should be focused on how people interact
with the system.  Once the architecural design has been completed, the 
technical engineers will apply their processes to insure that the building 
(or software system) won't fall down.

The role of the software architect was missing from my original post.  This 
person requires a unique blend of engineering, artistic, and cognitive 
awareness skills to design systems which interact well with people, and
are still readily engineered from a system structure perspective.
-- 
  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" 
