Guest Post by Jack Graham: A novel is an engineering project

Back in March, my colleague John Remy posted here about using kanban, a project management technique originally invented by Toyota engineers, to keep track of multiple short fiction projects. John and I have both worked in the Information Technology field – I as a software analyst. His post got me thinking about how I’ve re-purposed some of the mental equipment from my day job to make my writing more efficient.

Consider a novel as a big, complicated machine. You put materials – characters, situations, imagery – in one end, the machine churns on them for 300 pages, and what comes out the other end is changed somehow. In between, a succession of gears, conveyer belts, robot arms, and other parts act on the material, moving it along, reshaping it. It’s a complex task, designing a machine that does all this, and the first few times I tried to do it, I ended up with hundreds of thousands of words but no cogent story. Eventually, though, I realized that the software I help build in my day job had a lot in common with a novel.

I’m now a month into my fourth attempt at a novel, and it’s working (after trying to write – and scrapping almost entirely – the first two attempted drafts). Here are some techniques I stole from the software business to make it work.

Establish Scope First; Avoid Scope Creep

I picked a semi-arbitrary length of 100,000 words broken into twenty 5,000 word chapters. I’ve done enough writing now to know how much ground I can cover in a 5,000 word chapter. It might seem like a rigid framework, but I’ll stick to it as much as possible, for reasons discussed in the next section, and to avoid scope creep.

Scope creep is something that happens in both fiction and software projects. The project is humming along nicely toward its goal, when along comes an idea for a new feature. It’s tempting. Oh, it’s tempting. But if you add in something that doesn’t clearly move toward the final goal, you’re making the project longer. You’re complicating things, and risking getting the job done. Do like LeGuin and kill your darlings. Better, don’t even write that tangential thing in the first place if you can help it. File the idea away. It’ll be there later.

Synopsis = Requirements

Now I know that I’ve got twenty chapters, and I know how long they are. So I can write my requirements, which get documented in my synopsis.

In software, a requirement is a description of a piece of work your machine must perform. How it does the work isn’t so important as that it does do it.

Some people are born novelists, or they’ve been doing it long enough that all the mental processes I’m now inculcating in myself are second nature. Joe Haldeman quipped during Q&A after a reading at MIT last year that he usually sends in a synopsis and then writes a completely different novel. Works for him, I guess, but I need more structure than that.

My synopsis isn’t yet the final document I’ll use when submitting. The chapter summaries are spare, bullet-pointed, written for me to reference rather than as an enticement to a potential publisher. I’ll have to re-write it in salespitchese when I’m done.

It’s also got some key extras: dramatis personae; a timeline of world events; and since it’s a sci-fi novel, a summary of important technologies and social concepts.

Every Part Must Work to Requirements

If you listen to veteran novelists, they think of chapters and scenes as having requirements, even if they use different words. Every scene must have a purpose; it must do a piece of work. If it doesn’t, it shouldn’t be there. It’s scope creep.

On the positive side, the requirements provided by my synopsis give me concrete measurements of whether a scene or chapter achieved its purpose. Does the audience now know from this establishing scene that my talking bear detective is brilliant but a ginormous asshole? Do they also have that key piece of foreshadowing info they need to stay engaged? Yes, they do. Requirements met – next scene!

Keep Good Documentation

I’ve made my synopsis the core document describing my overall novel project. If I change something in the text, the synopsis gets updated accordingly, so that I can keep track of what I’ve done by reading the synopsis rather than skimming an entire chapter. This saves me from a huge time-suck I had on previous noveling attempts – re-familiarizing myself with stuff I’d already written.

We’ll see if all this works. It may be that I hit my January 31 deadline and have to go back to the drawing board yet again. But for now, it’s working, and I feel confident that I’m not wasting effort on another project that I won’t finish.

 

Descended from Norwegian illegal aliens, Jack Graham, like his dodgy, seafaring forebears, gets by on a good story and occasional back-breaking labor. He counts among his friends all cats everywhere and a giant, glowing North Woods insect manitou whom he cheerfully immolates annually at an orgiastic revel. He can neither confirm nor deny whether the Clarion West 2010 class is some kind of f&sf mafia. He has published some stories and games, but no novels.

Trackback URL

  • http://twitter.com/inkgorilla Andrew Penn Romine

    Timely post, Jack! I’m trying to get a handle on my novel and “scope creep” is exactly the problem I’m having.

    I used to be such a seat of the pants writer, but learning more and more how helpful those outlines & synposes are.

    Thanks for a great post and good luck on the book. (and I’m still looking forward to more detective bear stories btw) :)

  • http://twitter.com/jackgraham Jack Graham

    Oh, BTW, didn’t want to imply that Joe Haldeman has some secret magic that enables him to write novels without planning or note-taking. At the reading in question, he gave us a peek at the notebook he’d kept for his most recent project. I got the impression from this that he’s pretty big on documentation, too. :)

  • Pingback: R.S. Hunter - Official Website | The home of science fiction, fantasy, and speculative fiction author R.S. Hunter