Alec Nevala-Lee

Thoughts on art, creativity, and the writing life.

It’s not just an outline; it’s a prototype

with 7 comments

Miyamoto sketch for The Legend of Zelda

Today, I’m starting the rough draft of a new novelette that I’ve been brainstorming and researching for the last week and a half. As usual, I’ve begun by putting together a detailed outline of the entire story, and as tends to happen, it’s almost ludicrously comprehensive: the current version runs to about 7,000 words for a story that I expect to top out, after revision and cutting, at 10,000 words or so. I’ve justified this approach in the past by arguing that an outline like this is really more of a stealth first draft, allowing me to work out issues of plot and character without worrying about details of language and expression. And in approaching the writing process in this way, I’m unconsciously following the good advice of David Mamet:

As a writer, I’ve tried to train myself to go one achievable step at a time: to say, for example, “Today I don’t have to be particularly inventive, all I have to be is careful, and make up an outline of the actual physical things the character does in Act One.” And then, the following day to say, “Today I don’t have to be careful. I already have this careful, literal outline, and I all have to do is be a little bit inventive,” et cetera, et cetera.

All the same, I sometimes look at the outlines I write and wonder if they consume more of the process than they really should, and I’m occasionally reminded of Borges’s parable about the map of the empire that was the size of the empire itself.

Really, though, a detailed outline isn’t a map or a blueprint—it’s a prototype. Over the last month, I’ve been reading Jesse Schell’s appealing book The Art of Game Design, inspired by the fact that some of my most meaningful recent insights into structure and narrative have come from video games. Schell spends a long chapter discussing the importance of prototyping and testing, which he sums up as The Rule of the Loop: “The more times you test and improve your design, the better your game will be.” The problem, at least when you’re operating under a deadline, is that it’s hard to build and test a full working version of a complex system like a game—or a novel—more than a handful of times. And the solution is to start with a very rough model that addresses potential problems without troubling itself too much about quality. Schell advises game designers to employ the spiral model of software development, as conceived by the engineer Barry Boehm:

    1. Come up with a basic design.
    2. Figure out the greatest risks in your design.
    3. Build prototypes that mitigate those risks.
    4. Test the prototypes.
    5. Come up with a more detailed design based on what you have learned.
    6. Return to step 2.

The spiral model of software development

On its face, this isn’t so different from what most writers do: we start with a rough draft that we know isn’t going to be pretty, read it over to get a sense of the major issues, then take it through iterations of revision and editing until it starts to resemble the story we hoped to create—or takes a different, more surprising shape altogether. What’s worth remembering, though, is how rough that initial prototype can be. As Schell points out, when you’re designing a video game, you can make a version on paper to test the basic mechanics of the premise: you can cut Tetris pieces out of cardboard and slide them down a paper screen, or use graph paper to map out a level of a first-person shooter like Doom, pushing around cutout monsters while a player moves and attacks. It’s crude, and it can’t be mistaken for a finished game, but that’s part of the point: the rougher it is, the more likely you’ll see fundamental problems that a more polished version might have misled you into overlooking.

Which brings us back to the outline. The outlines I write are rough, ugly versions of entire stories, or of large sections of a novel, and reading them over before I start the day’s work allows me to think about the story on a relatively high level: I’ll often print it out and make changes by hand to fix things like transitions, the order of scenes, and anything that doesn’t seem clear or logical, which is much more efficient than confronting these problems after I’ve already begun the draft. Later, of course, there will be issues I can’t address directly until some version of the story itself has been written, but it’s rare that I’ll get that far only to find that some major element of the narrative is untenable, as occasionally happened in the old days. The result is a fast version of the loop that Schell describes, and it allows me to pack a greater number of iterations into the limited time that I have. An outline that approaches the length of the story itself may seem excessive, and it does consume a disproportionate amount of the process. But in the long run, it saves me a lot of trouble.

Written by nevalalee

June 5, 2013 at 8:46 am

7 Responses

Subscribe to comments with RSS.

  1. I cannot even pretend to know what it is like to plan a project so massive. A friend told me, however, that the key is to proofread, proofread, proofread…and to be unafraid to toss out something you have invested a lot of time in. That passage just may not be right for this book, etc. God be with you!


    June 5, 2013 at 8:52 am

  2. Agreed. Being willing to cut something that took days or weeks to write might be the single most important skill for any writer to acquire, along with the habit of finishing what you start.


    June 5, 2013 at 8:57 pm

  3. I never thought about The Rule of the Loop in terms of writing, but I definitely practice it in my daytime job. By day, I function as a computer programmer of sorts, writing code that combines elements from two different public health datasets into one dataset. Currently, I have several programs (chapters?) that I run sequentially to ultimately create an new dataset (a novel?). The Rule of the Loop applies. The base of the data are birth records and I have to run these programs for each birth year of data that we have. Every time I run the programs, I find ways to make them run more efficiently, to make them flow better and faster. OK, this isn’t the best analogy perhaps. I am testing and improving the design with each iteration. But it isn’t just deadlines that make The Rule of the Loop a problem for writing. It also that the Loop can run indefinitely until you decide it’s time to stop and consider the novel, the program code, complete and done. I appreciate this post; it’s given me another way to look at my writing.


    June 8, 2013 at 3:11 pm

  4. Thanks for sharing! I’ve become increasingly interested in the parallels between writing fiction and software development, to the point where I’m hoping to teach myself a bit of coding soon. If and when I end up writing more about this, I’d be curious to hear your thoughts…


    June 9, 2013 at 6:52 am

  5. It would be my pleasure. What code are you thinking of learning? I’m using SQL (Structural Query Language) and my experience is primarily in database management. I look forward to reading more.


    June 10, 2013 at 11:07 am

  6. I’m hesitating between Java, C, or C++. Any advice?


    June 10, 2013 at 9:55 pm

  7. Uh, oh. I’ve never worked with those languages. Sorry, I don’t know enough about of them to give advice :(


    June 11, 2013 at 7:10 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: