Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!gatech!usenet.ins.cwru.edu!mcs.kent.edu!rothstei
From: rothstei@mcs.kent.edu (Michael Rothstein)
Newsgroups: comp.software-eng
Subject: Re: Art vs. Engineering
Message-ID: <1991May9.155632.29277@mcs.kent.edu>
Date: 9 May 91 15:56:32 GMT
References: <1991May6.165902.2116@ssd.kodak.com> <35177@athertn.Atherton.COM>
Distribution: usa
Organization: Kent State University
Lines: 66

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.
>You had to be familiar with photo chemistry, lights, optics, the motion
>picture cameras, and the projectors.  Filmakers were largely very
>technical people.
>Today, filmaking is still a very technical discipline, various sound
>systems, types of lenses, camera equipment, complex film developing
>techniques plus special effects require as much technical know how as
>ever.  Yet the many engineers, and technicians are not in service of
>Film Scientists, but
>rather in service of Artistic Directors. 
>
(Many excellent thoughts on the future evolution as art/craft of software
development deleted to try to approach some reasonable size ;-))

Following this (and other) thread(s) in this group made me think: it may
be that the simile to follow when building software is more like building
buildings. Consider: 
a building is first designed by an ARTIST (the architect) who, though
somewhat knowledgeable on the limitations of his materials, really needs
an expert to help him:
a civil engineer, who can figure out the stresses of the suggested materials
and structures: the two specialties interact and negotiate a final design
satisfactory to both. The last stage, of course, is actual implementation.
 To continue this thought, how would the following scenario work?:
A SOFTWARE ARCHITECT would be in charge of developing the (functional)
requirements and user interface of the proposed system: he would be in
communication with a software designer (aka software engineer) who would
correct the requirements and interface design, and would later issue the
specifications (aka non-functional requirements) to complete the problem
definition stage. This stage would be subject to a review session and
a final (contract) signing.
The remainder of the software lifecycle could continue on as before,
with a design (done by the some software designer/engineer, not necesarily
the same one), walkthroughs, review, etc. etc.
   Though I personally feel that this idea of a software architect is
a necesary one, I owuld be interested in other people's reactions.
   Thank you for reading this far and for any responses!
-- 
Michael Rothstein (Kent State U)|	If cars want to kill themselves,
(rothstei@cs.kent.edu)		|	that's their problem: what I can't
			 	|	understand is why they keep doing it
(std. disclaimer)		|	with people inside. (Mafalda (Quino))