TITLE: Start With A Box
AUTHOR: Eugene Wallingford
DATE: May 16, 2005  3:41 PM
DESC: We can't create wonderful artifacts if we aren't prepared for inspiration.
-----
BODY:
<BLOCKQUOTE><EM>
before you can think out of the box,          <BR/>
you have to start with a <STRONG>box</STRONG> <BR/>
-- Twyla Tharp
</EM></BLOCKQUOTE>

I've been reading Twyla Tharp's <EM>The Creative
Habit</EM>, and that quote is the title of Chapter
5.  As soon as I read it, I scribbled it down
immediately on the note card I had tucked in the
back of the book for just such occasions.  The
idea of "starting with a box" struck me in a
particular way, and as I read the chapter I went
through a journey from thinking that Tharp meant
something else to thinking that, ultimately, we
were onto the same idea.  For Tharp, "the box" is
as organizational system, a way of storing and
managing her memory as she works on a new creative
project.  But the box is more than that -- it is
really about <STRONG>preparation</STRONG>.

Bobby Knight, the famous US college basketball
coach, once said something along the lines, "The
will to win is the most overrated desire in all
of sports.  Everybody has the will to win.  What
separates those who succeed is the will to
<EM>prepare to</EM> win."

I often encounter students who say that they can
be successful contributors in the software industry
despite their unwillingness to work hard to become
really good programmers -- because they will be
part of a team in industry.  I guess they figure
that some other member of the team is going to do
the heavy lifting.  My response to them is always
the same:  Why would a team want you as a member
if you can't help with the most important product
it produces?  That's awfully presumptuous of you.
For some folks, the desire not to program is borne
out of a lack of interest in programming.  But for
many it grows out of a lack of success, and a consequent
unwillingness to do the hard work needed to prepare
for programming tasks.

Most people can tell when they are unprepared for a
job, though our egos sometimes hide the truth from us.
Introductory students often come to my office with
questions about a programming assignment, saying,
"I know just what I want to do, but when I try to
write the program I just can't say it in Java."
(In earlier years, it was C++, or Pascal.)  Again,
my response is often the same:  You don't really
know what you want to say, or the program would come
more easily.  Tharp says so, too, using a journalist
as her example:

<BLOCKQUOTE><EM>
If his reporting is good, the writing will reflect
that.  It will come out quickly and clearly.  If
the reporting is shoddy, the writing will be, too.
It will be torture to get the words out.
</EM></BLOCKQUOTE>

Some may think that this all sounds bad for agile
methodologies, which de-emphasize months of on-project
preparation of requirements and design.  But I think
that this line of thought betrays a misunderstanding
of agile methods, one reflected in the idea that
they are reckless.  Unprepared developers cannot
write good software using an agile method.  Agility
doesn't mean not being prepared; it means letting
your preparation work in concert with concrete steps
forward to prepare you even better for what comes
next.

One thing I like about Tharp's chapter is that she
doesn't stop at "be prepared".  She reminds us that
preparation is only preparation.

<BLOCKQUOTE><EM>
The box is not a substitute for creating.  The
box doesn't compose or write a poem or create
a dance step.  The box is the raw index of your
preparation.  It is the repository of your creative
potential, but it is not  that potential realized.
</EM></BLOCKQUOTE>

You still have to create!  You have to write code.
You have to pull your head out of design-land, out
of the code library, out of the archives and
actually begin writing code.

<BLOCKQUOTE><EM>
Sadly, some people never get beyond the box stage
in their creative life.  We all know people who have
announced that they've started work on a project ...
but some time passes, and when you politely ask how
it's going, they tell you that they're still researching.
... Maybe they like the comfort zone of research as
opposed to the hard work of writing.  ... All I know
for sure is that they are trapped in the box.
</EM></BLOCKQUOTE>

Some students do this, too.  They work hard -- they
really do -- but when the assignment comes due, there
is no program to turn in; they never got around to
actually <EM>producing</EM> something.  And the
program is the whole point of the assignment.  Okay,
okay, <STRONG>learning</STRONG> is probably the real
point of the assignment, but you can't learn what
you really need to learn until you write the program!

This is where we can see a strong connection to the
agile methods.  They encourage us to be in a continuous
state of writing small bits of code, testing and designing,
cycling quickly between planning and producing.

Tharp ends her chapters with exercises for the reader,
activities that can help readers work on the idea
they've just read about.  The section at the end of
"start with a box" consists of a single exercise,
and it's not especially concrete,.  But it does have
an agile feel to it.  When you are having a hard time
getting out of the box, take a big leap somewhere in
the project.  Don't worry about the beginning or the
end; just pick something, an especially salient point
(or user story)  and get to work.  <EM>You never know
where it will take you.</EM>

"Getting out of the box" was one of the primary
motivations for me starting my blog.  I had boxes
and boxes of stuff (metaphorical boxes, of course
-- mine were either computer files or file folders
stuffed with hastily written notes).  But I had
stopped taking the risk of putting my thoughts out
in the public space.  In that regard, this blog has
been a huge success for me.
-----