TITLE: Experiments in Art and Software
AUTHOR: Eugene Wallingford
DATE: December 21, 2005  5:07 PM
DESC: 
-----
BODY:
<A HREF="http://www.pyracantha.com/cgi-bin/blosxom.cgi">
   <IMG SRC="http://www.pyracantha.com/images/929B%20Double%20Planet%20Web.jpg"
        ALT="Double Planet, by Pyracantha"
        ALIGN="right"
        WIDTH="225"></A>

<A HREF="http://www.pyracantha.com/cgi-bin/blosxom.cgi">
   Electron Blue</A>
recently wrote about some of her
<A HREF="http://www.pyracantha.com/cgi-bin/blosxom.cgi/2005/11/24#EB201Art%20Experiments">
   experiments in art</A>.
As an amateur student of physics, she knows that these
experiments are different the experiments that scientists
most often perform.  She doesn't always start with a
"hypothesis", and when she gets done it can be difficult
to tell if the experiment was a "success" or not.  Her
experiments are opportunities to try ideas, to see whether
a new technique works out.  Sometimes, that's easy to
see, as when the paint of a base image dries with a grainy
texture that doesn't fit the image or her next stage.
Other times, it comes down to her judgment about balance
or harmony.

This is quite unlike many science experiments, but I think
it has more in common with science than may at first appear.
And I think it is very much like what programmers and
software developers do all the time.

Many scientific advances have resulted from what amounts
to "trying things out", even without a fixed goal in
mind.  On my office wall, I have a wonderful little news
brief called "Don't leave research to chance", taken from
some Michigan State publication in the early 1990s.  The
article is about some work by
<A HREF="http://www.psl.msu.edu/faculty/rootbern.htm">
   Robert Root-Bernstein</A>,
an MSU science professor who in the 1980s spent time as
a MacArthur Prize fellow studying creativity in the
sciences.  In particular, it lists ten ways to increase
one's chances of serendipitously encountering valuable
new ideas.  Many of these are strict matters of technique,
such as removing background "noise" that everyone else
accepts or varying experimental conditions or control
groups more widely than usual.  But others fit the art
experiment mold, such as running a reaction backward,
amplifying a side reaction, or doing something else
"unthinkable" <EM>just to see what happens</EM>.  The
world of science isn't always as neat as it appears
from the outside.

And certainly we software developers explore and play
in a way that an artist would recognize -- at least
we do when we have the time and freedom to do so.
When I am learning a new technique or language or
framework, I frequently invoke the
<A HREF="http://www.cs.uni.edu/~wallingf/patterns/pedagogical/three-bears.html">
   Three Bears Pattern</A>
that I first learned from Kent Beck via one of the
earliest
<A HREF="http://www.pedagogicalpatterns.org/">
   pedagogical patterns</A>
workshops.  One of the instantiations of this pattern
is to use the new idea everywhere, as often and as
much as you can.  By ignoring boundaries, conventional
wisdom, and pat textbook descriptions of when the
technique is useful, the developer <EM>really</EM>
learns the technique's strengths and weaknesses.

I have a directory called <TT>software/playground/</TT>
where I visit when I just want to try something out.
This folder is a living museum of some of the
experiments I've tried.  Some are as mundane as
learning some hidden feature of Java interfaces,
while others are more ambitious attempts to see
just how far I can take the Model-View-Controller
pattern before the resulting pain exceeds the benefits.
Just opportunities to try an idea, to see how a new
technique works out.

My own experience is filled with many other examples.
A grad student and I learned pair programming by giving
it a whirl for a while to see how it felt.  And just
a couple of weeks ago, on the plane to Portland for the
<A HREF="http://www.oopsla.org/2006/">
   OOPSLA 2006</A> fall planning meeting, I whipped
up a native
<A HREF="http://www.dangermouse.net/esoteric/ook.html">
   Ook!</A>
interpreter in Scheme -- just because.  (There is still
a bug in it somewhere... )

Finally, I suspect that web designers experiment in
much the way that artists do when they have ideas
about layout, design, and usability.  The best way
to evaluate the idea is often to implement it and
see what real users think!  This even fits Electron
Blue's ultimate test of her experiments:  How do
people react to the work?  Do they like it enough to
buy it?  Software developers know all about this,
or should.

One of the things I love most about programming is
that I have the power to write the code -- to make
my ideas come alive, to watch them in animated bits
on the screen, to watch them interacting with other
people's data and ideas.

As different as artists and scientists and software
developers are, we all have some things in common,
and playful experimentation is one.
-----