Since then, I've had a couple more thoughts about the process. First, I found that I am going to have to do a major restructuring of my NaNoWriMo book if I want to whip it into publishable shape. I organized the major objects (that is, the scenes and chapters) in a more or less chronological order, so the point of view flips around. However, this gives a lot of stuff away too early, and makes it hard to see the characters develop. So I'm probably going to rearrange things, so that the story is told entirely from one character's point of view up through the point where everybody's in the same place together. Then, if I can make it work, I'll go back and catch up the essentials from the other characters' points of view. Hey, if Tolkein could make it work in Lord of the Rings...
Software people have a word for this: refactoring. You've got the right collection of interacting objects, but they're arranged incorrectly. Re-arrange them, adjust the interactions, reorganize the stuff so that it works the way you want it to.
I'm still stuck on the idea that it ought to be possible to write the 50,000 words of NaNoWriMo without simply ignoring quality, though. This leads me to wonder if I could apply the principles of agile software development to a book-writing sprint. The relevant concepts are these:
- You build incrementally. Each new addition represents a meaningful new "story."
- At all times, the thing you've built is functional. In the case of software, this means that you always have a working system; each addition simply extends the set of things it'll do. In the case of growing a novel, it means (I think) that you start with a simple story or scene, which is a complete tale in itself, but which grows in the telling.
- You test continually. Each new feature is accompanied by tests to assure that all the old stuff still works. I think for a high-speed novel, this would require working in teams--I read yours while you read mine, every day.