Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!mips!apple!voder!pyramid!athertn!hemlock!mcgregor
From: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Newsgroups: comp.software-eng
Subject: Re: Art vs. Engineering
Message-ID: <35202@athertn.Atherton.COM>
Date: 9 May 91 23:28:08 GMT
References: <1991May9.124559.2924@ssd.kodak.com> <1991May6.165902.2116@ssd.kodak.com> <35177@athertn.Atherton.COM>
Sender: news@athertn.Atherton.COM
Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Distribution: usa
Organization: Atherton Technology -- Sunnyvale, CA
Lines: 127

In article <1991May9.124559.2924@ssd.kodak.com>, nichols@ssd.kodak.com
(Tim Nichols (37894)) writes:

>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).

Of course, not all films are art or entertainment films.  As Tim notes,
film is a common medium for education, and communication as well. Considerable
amounts of user oriented software has these as dominant attributes as well.
For example, there are structured design and structured analysis CASE tools
such as from Cadre and IDE.  Part of what they offer is that they are
*communicating* to you information from their "experts" with the hope of
*educating* you in currently recognized techniques for improved design
and analysis.  The software not only educates you, but helps you in the
formation of presumably beneficial design habits.

For user oriented software, a growing amount of the product is not
merely the manipulation that the software does, but also its user manual, on
line help, computer based training, off-line training, and design
aspects which make it easy to learn, and (contrary to what Tim stated
below) to easy to remember how to use.

Additionally, in a competative commercial market, there is value in a
product which is "entertaining" over a competing product with the same
capability but without the endearing facade. This doesn't always mean
that "entertainment" is frivolous, but some features give people a "good
feeling".  The macintosh user interface, including its "entertaining" as
well as educational guided tour is a frequently cited example.  One can
also determine a general common preference for the HP widgets 3D
appearance version over their 2D versions, despite the
fact that they behave the same way, and have approximately the same  
visual recognition rates.

>  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 believe that this is an over simplification.  It is important to distinguish
the use of long term memory from short term memory.  People don't have
much short term memory (by analogy, we only have a few registers).  Thus
it is very important to avoid overloading that short term memories with
tasks that relate to the software, and not to the underlying task.  If a
software product is not memorable, you will be forced to relearn it
every time you use it, and this learning (and transitory remembering of
which button does which function) competes with the underlying task for
short term memory, and degrades the task performance--introducing not
only delay, but frequently also introducing error as well, and of course
the well known "now where was I?" phenomenon (swapping).

To avoid this problem, it can be claimed that good software should not
be noticed.  This is true, though the way it is most likely to be
achieved is through the use of "long term memory", generally in the form
of habits. Because people are able to handle much more long term memory,
 there is not the kind of interaction problems as when short term memory
is being competed for.  Habit formation is critical for "seemingly
effortless" performance of complex tasks using complex tools.  In this
respect, the memorability of many software features, like a good movie,
is critical to success.  (There is considerable literature on this
point, I particularly like Norman, Schniederman, Nelson, and Malone's
papers that touch on these points.  But for a short often used example,
consider learning to drive an automobile.  Until you build habits,
driving is a very engrossing activity--it is hard to even control your
speed.  Once you develop the habits, it is possible to drive and do
other things as well, such as carry on a conversation. There is still
some interaction, and tests can show that both activities may be
degraded over what can be done if doing only one.  But even so,
performance levels are significantly higher than during the pre-habit
formation learning period. And then of course, it is fair play to re-use
existing learned complex habits, such as in using the same sort of
steering mechanism and accelerator pedal in a speed boat.  Good software
also takes advantage of these existing memorable habits).

So I would conclude that given software aimed at making us work smarter
and faster it is *crucial* that we learn to make it more memorable and
enjoyable to use. 

> 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.

This is a very provocative alternative that I think deserves
considerable thought.  As you point out, an architect model requires a
person that combines both the technical and artistic aspects in one
person, and this is very different from the scientist model in the
original article.  It may be a better model, or it may merely be a model
which is better for an additional subdomain. In my previous posting, I
identified a domain where the software scientist model was perhaps more
appropriate, and one where an artistic model might be more appropriate.
The building architect model is interesting in that buildings are
physical objects, just computers are.  An architecture model might be
very appropriate for a systems integrator house which is concerned with
soup-to-nuts hardware + software solutions.  But the filmaker model has
its merits too, in that buildings, and their architectural drawings are
more static, whereas film and many forms of software (including all the
computer based and off line training capablities) are more concerned
with dynamic ephemeral fleeting images. Perhaps for some task domains,
the interactivity demanded of the software is more akin to the "quick
cuts" techniques of filmmaking.  If so,
does this put additional artistic demands upon the designer which over
task someone who must also be designing from a technical point of view>

Might this be another way of saying that the software industry is really
many industries, and that the dominant factor affecting organization of
the development team is end market for which the software is targetted? 
(Johnathan Grudin's article in April 1991 Computer comes to mind). 
Perhaps what this really argues for is a continuum of development
approaches from the pure technical dominant (scientist) driven model,
through the mixed art/technical (architect) model to the pure art
dominant model (filmmaker)?

Scott McGregor
Atherton Technology
mcgregor@atherton.com