TITLE: Learning About Software from The Theater, and Vice Versa
AUTHOR: Eugene Wallingford
DATE: November 28, 2007 3:33 PM
DESC:
-----
BODY:
Last Sunday was my fourth rehearsal as a
newly-minted actor.
It was our first run-through of the entire play on stage,
and the first time the director had a chance to give notes
to the entire cast. The whole afternoon, my mind was
making connections
between plays and programs -- and I don't mean the playbill.
These thoughts follow from my experiences in the play and
my experiences as a software developer. Here are a few.
Scenes and Modularity Each
scene is a like a module that the director debugs. In some
plays, the boundaries between scenes are quite clean, with
a nice discrete break from one to the next. With a play
on stage, the boundaries between scenes may be less clear.
In our play, scenes often blend together. Lights go down
on one part of the stage and up on another, shifting the
audience's attention, while the actors in the first scene
remain in place. Soon, the lights shift back to the first
and the action picks up where it left off. Plays work this
way in part because they operate in limited real estate,
and changing scenery can be time-consuming. But this also
It is easier to debug scenes that are discrete modules.
Debugging scenes that run together is difficult for the same
reasons that debugging code modules with leaky boundaries is.
A change in one scene (say, repositioning the players) can
affect the linked scene (say, by changing when and where a
player enters).
Actors and Code If the director
debugs a scene, then maybe the actors, their lines, and the
props are like the code. That just occurred to me while
typing the last section!
Time Constraints It is hard to
get things right in a rush. Based on what he sees as the
play executes, the director makes changes to the content of
the show. He also refactors: rearranging the location of
a prop or a player, either to "clean things up" or to
facilitate some change he has in mind. It takes time to
clean things up, and we only know that something needs to
be changed as we watch the play run, and think about it.
Mock Objects and Stand-Ins When
rehearsing a scene, if you don't have the prop that you will
use in the play itself, then use something to stand in its
place. It helps you get used to the the fact that something
will be there when you perform, and it helps the director
remember to take into account its use and placement. You
have to remember to have it at the right time in the right
place, and return it to the prop table when it's not in use.
A good mock prop just needs to have some of the essential
features of the actual prop. When rehearsing a scene in
which I will be carrying some groceries to the car, I grabbed
a box full of odds and ends out of some office. It was big
enough and unwieldy enough to help me "get into the part".
Conclusion for Now The
relationship between software and plays or movies is not a
new idea, of course. I seem to recall a blog entry a couple
of years ago that explored the analogy of developing software
as producing a film, though I can't find a link to it just
now. Googling for it led me to a page on
Ward's wiki
and to
two
entries
on the Confused of Calcutta blog. More reading for me...
And of course there is Brenda Laurel's seminal
Computers As Theatre.
You really should read that!
Reading is a great way to learn, but there is nothing quite
like living a metaphor to bring it home.
The value that comes from making analogies and metaphors
comes in what we can we learn from them. I'm looking forward
to a couple of weeks more of learning from this one -- in
both directions.
-----