TITLE: It's a Wrap
AUTHOR: Eugene Wallingford
DATE: December 10, 2007  1:19 PM
DESC: 
-----
BODY:
My first run as an
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2007-11.html#e2007-11-28T15_33_59.htm">
   actor</A>
has ended without a Broadway call.  Nonetheless I consider it
to have been successful enough.  My character didn't cause any
major interruptions in the flow of our three performances, and
I even got us back on track a time or two.  Performing in front
of a crowd -- especially a crowd that contained personal friends
-- was enough different from giving a lecture or speaking in
public that it wracked a few nerves.  But getting a laugh from
a real audience was also enough different from a laugh in a
lecture, too, and the buzz could feed the rest of the performance.

My first post on this topic recorded dome thoughts I had had on
the relationship between developing software and directing a
play.  In those thoughts, the director or producer is cast as
the software developer, or vice versa.  In the last couple of
weeks, my thoughts turned more often to my role as performer.
Here are a few:
<UL>
<LI> Before each rehearsal and performance, I found myself
     spending important minutes setting up my environment:
     making sure props were in place, adjusting positions based
     on any results from the last time, and finding a place
     backstage for my time between scenes.  This felt a lot
     like how I set up for time writing code, getting my tools
     in place.

<LI> I wonder if there is any analogue in software development
     the self-consciousness I felt as I began to perform on
     stage?  Over time, the director helped me to morph some
     of the self-consciousness into a sensitivity to the scene
     and my fellow players.

     After a while, experience helps push self-consciousness
     into the background.  It was even possible to get into a
     <A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-03.html#e2005-03-04T16_06_50.htm">
        flow</A>
     where the self disappeared for a moment.  I think I need
     more experience in character to have more experiences like
     that!  But those moments were special.

<LI> Once we got into performances, I noticed a need for the
     same almost contradictory combination of hubris and humility
     that a programmer needs.  At some point, I had to know my
     lines and scenes so well that I could nail them blind.
     That drove a form of confidence that let me "own" my
     character in a scene.  Yet I had to be careful not to
     become too cocky, because suddenly something would go wrong
     and I'd find myself exposed and not at all in control.  So
     I spent a few minutes before every scene preparing, just
     refreshing my memory of cues and placements and notes the
     director had given.  That bit of humility gave me more
     confidence than I otherwise could have had.
</UL>

Most of the relationships I noticed between acting in the play
and building software were really patterns of good teams.  In
every scene I depended upon the presence and performance of
others -- and they depended on me.  Being a good teammate
mattered both on stage (while performing) and off (when
preparing and when taking and giving feedback).  "The key to
acting," said our director, "is listening to other people."
Funny how that is the key to so many things.

As I look back on this (first?) experience being a player in
a stage production, I think that there is a lot to this notion
that developing software is like producing a play -- and that
producing a play is like developing software.  The two media
are so different, but they are both malleable, and both
ultimately depend on their audiences (users).

Over the course of two weeks or so, the director did a lot
of what I call refactoring.  For example, he found the
equivalent of duplicated code -- lines and even larger parts
of scenes that don't move the story forward, given how the
rest of the play is being staged.  Removing duplicated stuff
frees up stage real estate and time for making other additions
and changes.  He also aggressively sought and deleted dead
space -- moments when no one was on stage (say, in the transition
between scenes) or no active was taking place (say, when
lighting changed).  Dead space kills the energy of the show
and distracts the viewer.  Dead space is a little like dead
code and over-designed code -- code that isn't contributing
to the application.  Cut it.

Every night after rehearsal and even shows, the director "ran
notes" with us.  This was a time after each "iteration"
dedicated to debugging and refactoring.  That's good practice
in software.

One other connection jumped out to me yesterday.  After we
closed the show, I was chatting with 
<A HREF="http://www.scottwsmith.com/">
   Scott Smith</A>,
a local filmmaker whose is real-life husband to the woman who
played my wife in the show.  We were discussing how filmmaking
has changed in the last decade or so.  In the not-so-old days
folks in video were strongly encouraged to become specialists
in one of the stages: writing, directing, shooting, editing,
and so on.  Now, with the wide availability of relatively
inexpensive equipment and digital tools, and economic pressures
to deliver more complete services, even veterans such as Smith
find themselves developing skills across the board, becoming
not a jack-of-all-trades but master of none, but rather strong
in all phases of the game.

I immediately thought of extreme programming's rapid development
cycle that requires programmers to be not only writers of code
but also writers of stories and tests, to be able to interact
with clients and to grow designs and architectures.  It's hard
to be a master of all trades, but the sort of move we have seen
in software and in filmmaking from specialist to generalist
encourages a deep competence in all areas.  Too often I have
heard folks say "I am a generalist" as way to explain their
lack of expertise in any one area.  But the new generalist is
competent across the board, perhaps expert in multiple areas,
and able to contribute meaningful to the whole lifecycle.

One last idea.  Just before our final show, the director gave
us our daily pep talk.  He said that come performers view the
last show as occasion to do something wacky -- to misplace
someone's prop, or deliver a crazy line not from the script,
or to affect some voice or mannerism on stage.  That sounds
like fun, he said, but remember:  <EM>For the audience out in
the seats today, this is the first show.</EM>  They deserve
to see the best version of the show that we can give.  For
some reason, I thought of software developers and users.  Maybe
my mind was just hyperactive at that moment when we were about
to create our illusion.  Maybe not.
-----