[comp.software-eng] Creativity in Computing

ghm@ccadfa.adfa.oz.au (Geoff Miller) (05/14/91)

dedek@meaddata.com (Mike Dedek) writes:

>.... compsci is similar to photography; there will be applications
>which are more 'scientific' and those which are more 'artistic'.  The
>line differentiating these is blurred.  The really great breakthroughs
>in compsci will be at least partly artistic, because they will be so
>radically different from the status quo that some creative effort will
>be necessary.  

I missed the start of this thread, but I want to take up the point that Mike 
makes above.  There is an implication here that creativity is only involved
in the "really great breakthroughs", and I disagree with this.  Programming
is essentially creative  -  look at the enthusiasm which some of the best
programmers put into their work, and you will see exactly the same 
concentration and demand for perfection as you see in the work of any other
artist.  Sure, there are a lot of hack programmers who just worry about
producing so many lines of code per day, but just an an author can agonise
for hours over finding just the right word so a real programmer will put a
lot of effort into every line of a program.  Mike's comparison with photography
is interesting, and I think valid, because in both cases the creativity is
applied within a tight discipline  -  perhaps a better comparison would be 
with poetry, where the chosen form of the poem provides tight constraints.
Many people can write passable verse, few can write poetry.

Geoff Miller  (ghm@cc.adfa.oz.au)
Computer Centre, Australian Defence Force Academy

duncan@ctt.bellcore.com (Scott Duncan) (05/14/91)

In article <2382@ccadfa.adfa.oz.au> ghm@ccadfa.adfa.oz.au (Geoff Miller) writes:
>
>                                                                Programming
>is essentially creative  -  look at the enthusiasm which some of the best
>programmers put into their work, and you will see exactly the same 
>concentration and demand for perfection as you see in the work of any other
>artist.

While I'd agree that "enthusiasm," "concentration," and "demand for perfection"
may all be necessary for something to be called "creative" in some sense.  One
can possess these characteristics, probably, and not be "creative" in the sense
of "original."  And one can be "original" without, say, "demand for perfection"
as an example.

>         Sure, there are a lot of hack programmers who just worry about
>producing so many lines of code per day, but just an an author can agonise
>for hours over finding just the right word so a real programmer will put a
>lot of effort into every line of a program.

I'm not sure this qualifies as "creativity" as much as dedication to doing the
job well, i.e., with high quality and concern for the client/user.

>                                                         the creativity is
>applied within a tight discipline  -  perhaps a better comparison would be 
>with poetry, where the chosen form of the poem provides tight constraints.

I think you have an important element here:  working within constraints or a
discipline (or at least knowing full well when the constraints are violated).
This seems to be high on many people's list of things that confer a sense of
engineering rigor on software development.  Interestingly you correlate it
with creativity which, I think, reveals what many hope an engineering approach
to software can achieve:  allow for creativity to coexist with some aspect of
standards, discipline, and constraints.

>Many people can write passable verse, few can write poetry.

You are not paralleling the writing of "passable verse," I hope, with "hack
programmers."  Since you compare both to folks whom you offer as examples of
"creative" people -- "real programmers" and the "few" who "can write poetry,"
I'd be concerned.

The writing of verse and the writing of software certainly have different
implications for the impact of how well the job is done.  Poorly done verse
is not likely to have the same effect as poorly done software.  One may com-
pare the process of creation, but the consequences of the latter seem far more
serious.

>Geoff Miller  (ghm@cc.adfa.oz.au)
>Computer Centre, Australian Defence Force Academy

Some time ago, I posted a note related to creativity where I suggested that
it had long been associated with implementation (algorithmic) concerns rather
than application (design) ones.  I did not hear from anyone at that time on
this point.  However, given Geoff's post, perhaps the comment bears repeating.

Do folks think that "creativity" in software is still very much focused on
the implementation of algorithms rather than the solution of an application
problem?  In some sense, even the excitement over object-oriented approaches
seems to get back to the creation of methods and classes and components.  It
seems to be left to the methodologists to discuss how this technology can be
applied to solving real-world problems.  And "methods" (one element of the
"discipline" Geoff mentions) have not always been popular with "real program-
mers."

Speaking only for myself, of course, I am...
Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan)
                (Bellcore, 444 Hoes Lane  RRC 1H-210, Piscataway, NJ  08854)
                (908-699-3910 (w)   609-737-2945 (h))

jls@netcom.COM (Jim Showalter) (05/16/91)

duncan@ctt.bellcore.com (Scott Duncan) writes:

>Some time ago, I posted a note related to creativity where I suggested that
>it had long been associated with implementation (algorithmic) concerns rather
>than application (design) ones.  I did not hear from anyone at that time on
>this point.  However, given Geoff's post, perhaps the comment bears repeating.

>Do folks think that "creativity" in software is still very much focused on
>the implementation of algorithms rather than the solution of an application
>problem?  In some sense, even the excitement over object-oriented approaches
>seems to get back to the creation of methods and classes and components.  It
>seems to be left to the methodologists to discuss how this technology can be
>applied to solving real-world problems.  And "methods" (one element of the
>"discipline" Geoff mentions) have not always been popular with "real program-
>mers."

Henry Ford said an engineer was someone who could do for a dime what any
damn fool could do for a dollar. I think this is as applicable to the realm
of software as it is to any other technical discipline. A software engineer
looks for justifications for NOT writing yet another piece of code. If a
chunk of software is available off-the-shelf that meets the criteria of the
application, then a software engineer will HAPPILY use it instead of running
out to reinvent the wheel for the eleventy-thousandth time--the software
engineer does not regard this as "cramping" his/her creativity: quite the
contrary, the creativity in this case was in recognizing this clever way
to avoid writing some code and thereby save the project lots of time and
money. Emphasizing creativity only where it concerns algorithmic implementation
not only wastes time and money, but gives programmers a greatly inflated
sense of their contribution to the project, particularly since, to a large
extent, programming in the small is a relatively trivial achievement (it can't
be all that difficult--MILLIONS of people know how to do it, in contrast
with the scarcity of those who can devise a good architecture for an entire
project). As software managers become increasingly sophisticated and savvy
about the BUSINESS side of things, it is my fervent hope that software
production will become increasingly disciplined, constrained, business-focussed,
and less and less "creative" (as the term is currently understood).
-- 
**************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 *****************
* Proven solutions to software problems. Consulting and training in all aspects*
* of software development. Management/process/methodology. Architecture/design/*
* reuse. Quality/productivity. Risk reduction. EFFECTIVE OO techniques. Ada.   *

daves@hpopd.pwd.hp.com (Dave Straker) (05/16/91)

>>This is probably a matter of interpretation. I would define Art as
>>being based in 'feelings' and Science as been based in 'rules'.
>>If there is a key word I would use for Engineering, it would be
>>'pragmatic'. Do what works. This would tend to push it towards
>>the Science end of the spectrum, although there are still elements
>>where 'feeling' is appropriate - such as in the design of a user interface.

>What you're talking about, Dave, is the feelings of the person who is doing
>the engineering.  IMHO, the feelings of the observers are more important in
>distinguishing what is art.  I think that both artists and engineers feel

An intelligent comment; and the observer of a programmer's code is
the maintainer! I have maintained code which I would class as beautiful.
It was well commented, well structured, use good naming, etc. A joy to
maintain. I've also maintained monolithic nightmares - some extremely
'clever' (which the programmer no doubt thought of as 'art').

The art of coding should be separated from the art of specification
and design - which the user of the program encounters. It is quite
possible to have appallingly unmaintainable code in a highly usable
and delightful product.

>Regards, Jane.

Regards to you too :-)

Dave Straker            Pinewood Information Systems Division (PWD not PISD)
[8-{)                   HPDESK: David Straker/HP1600/01
                        Unix:   daves@hpopd.pwd.hp.com

daves@hpopd.pwd.hp.com (Dave Straker) (05/18/91)

>The conclusion of this posting is that software engineering is still
>pre-paradigm as evidenced by the lack of a generally agreed upon way
>of looking at software, AND the weakness of the supporting science,
>computer science.  HOWEVER, software is such a gosh-dern useful thing,
>people are willing to shell out big bucks for sub-otpimal solutions.

Sounds reasonable to me. (but is it art ;@)

>of a scientific discipline.  The second reference is an article by
>Mary Shaw of Carnegie Mellon University, "Propsects for an Engineering
>Discipline of Software."  This article examines a definition of

Can you give the full reference to this, please?

>
>--Tom Sarver

Dave Straker            Pinewood Information Systems Division (PWD not PISD)
[8-{)                   HPDESK: David Straker/HP1600/01
                        Unix:   daves@hpopd.pwd.hp.com

tsarver@andersen.uucp (Tom Sarver) (05/20/91)

In article <36650013@hpopd.pwd.hp.com> daves@hpopd.pwd.hp.com (Dave Straker) writes:
>>The conclusion of this posting is that software engineering is still
>>pre-paradigm as evidenced by the lack of a generally agreed upon way
>>of looking at software, AND the weakness of the supporting science,
>>computer science.  HOWEVER, software is such a gosh-dern useful thing,
>>people are willing to shell out big bucks for sub-otpimal solutions.
>
>Sounds reasonable to me. (but is it art ;@)
>
It is art if you consider an artisan as one who chooses from a quasi-
infinite number of possibles to accomplish a goal with a subjective
means of measuring progress towards the goal.  It is the difference
between objective and subjective, codified knowledge and apprenticeship.

>>of a scientific discipline.  The second reference is an article by
>>Mary Shaw of Carnegie Mellon University, "Propsects for an Engineering
>>Discipline of Software."  This article examines a definition of
>
>Can you give the full reference to this, please?
>
I apologize.  I intended to give the reference before the summary.  It is
in _IEEE Software_, November 1990.

>>
>>--Tom Sarver
>
>Dave Straker            Pinewood Information Systems Division (PWD not PISD)
>[8-{)                   HPDESK: David Straker/HP1600/01
>                        Unix:   daves@hpopd.pwd.hp.com

--Tom Sarver
tsarver@andersen.com