NaNoWriMo, One More Time...

I went to the end-of-the-event "thank goodness it's over" party for National Novel Writing Month (the Naperville chapter of it, anyway) over the weekend, and picked up a couple more small insights into the ways in which NaNoWriMo reminds me of software projects I'd worked on (I've written two previous posts on the subject; you can read them here and here).

First, I heard from a few people that I'm wrong to assume they start with a blank piece of paper on November 1 and just start writing like mad. Many, it seems, plan for one or two months (some longer than that). They sketch out characters and setting, come up with plot, maybe even outline the whole book so that they're all ready to start hammering out words when the month officially begins. Hmm. At this point NaNo begins to look a lot like the coding step of a software project done under an old-fashioned waterfall model, doesn't it?

Let's look at this for a moment: some forty years ago, Fred Brooks observed that coding accounts for perhaps one-fourth to one-sixth the total effort in a software project. Another quarter-to-third is taken in design and architecture (if the project's being done well), and as much as a half is spent testing and bug-fixing. So, if somebody spends two months before NaNoWriMo planning and outlining (that is, designing), and three months afterward editing (testing and fixing), then producing an actual book that's ready to submit for publication should take about six months. Of course, most NaNo participants admit to banishing all other activities during the month of November, so it might be more accurate to say they get two months' worth of work (at a more "normal" level of activity) done during the NaNo event, which would suggest an overall book cycle of two months planning, two months (at a normal pace) writing the draft, and four to six months for editing and fixing.

So what? Well, probably nothing in the case of NaNoWriMo, as people are just doing this for their own amusement. But perhaps it is a symptom of a human behavior that shows up in projects as well: the tendency to see "the project" as only the stage where something countable is being made, and thereby underestimate its overall size. NaNoWriMo, like the coding stage of a software project, is the part of the iceberg that's above the surface. Perhaps that's why so few NaNo books have made it into print: when participants finish the month of writing and see how much work remains, they just quietly give up. Rather like software projects that get into unit test, only to find out how much work actually remains, and quietly fade away.

Then again, perhaps so many NaNo novels don't ever get through editing simply because their authors aren't interested in editing. Peruse the NaNoWriMo forums, and you'll see a lot of messages in which people are already planning or counting down to next November, already talking about the next novel they're going to write. Rather like people I knew who liked to write code, but didn't particularly like to do design, architecture or testing. Go figure.

So, what's the point? I'm not sure. David Schmaltz thinks I've got enough here for another article, but so far all I've got is a series of observations, particularly observations of similarity. Where's the aha!, the insight, the point? Stay tuned...