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:
before you can think out of the box,
you have to start with a box
-- Twyla Tharp
I've been reading Twyla Tharp's The Creative Habit, 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 preparation. 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 prepare to 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:
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.
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.
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.
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.
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.
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 producing something. And the program is the whole point of the assignment. Okay, okay, learning 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. You never know where it will take you. "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. -----