Sometimes, just for the hell of it, I’ll think, “What if we approached (discipline X) the same way we approach (discipline Y)?” Mostly I do this because it’s amusing, but as a wannabe novelist, I can also make the excuse that it brings up some interesting story ideas.
One of these story ideas is, “What if people approached spellcasting the same way they approach computer programming?” I’ve got visions of mages hunched over their PDAs, writing spells test-first, searching for the latest open-source code on grimoire.google.com. It’s a fun contrast against the usual idea of spellcasters waving their hands and saying weird incantations.
A couple of nights ago, as I was drifting off to sleep, a new idea occurred to me: What if I approached writing the same way I approach programming?
Well, let’s see. Since I do Extreme Programming at work, then I guess I would be doing Extreme Fiction.
I would have a bunch of “story cards”, each representing some new customer value my book is supposed to deliver. Things like, “Hero gets the girl in the end”, or “The running-away scene isn’t believable enough — add an argument scene to set the stage”. I’ve actually used something a bit like this before: write each plot point on an index card. But in the Extreme Fiction world, each card would include a time estimate.
Of course this would be a team effort. Pair Writing would be mandatory for all production text. And there’d probably be a Fiction Manager, and of course the On-Site Customer.
The Customer, as in XP, would be someone to make business decisions: someone who knows what the market wants, can write the story cards for each new enhancement, and can decide, once the writers put their estimates on the cards, which ones are most important each week, and which aren’t worth the cost. Maybe this person would be an editor from the publishing house, or the person who makes the purchasing decisions for a bookstore or library. Or a big-name author (who’s proven they can come up with stuff that sells). Or maybe just a fan of the genre.
At each weekly Planning Game, the Customer would look at the time estimates made by the writers, and would decide which story cards are most important for that week’s iteration. And there would be the standard daily Stand-Up Meeting, where everyone on the team would say what they worked on yesterday, what they plan to work on today, and what obstacles they’re facing (“We’re having a hard time making the sex scene work, so if anyone has any ideas, see us after the meeting”).
The team would, of course, practice Shared Story Ownership: everyone owns the entire story. Two people at a keyboard are all-powerful: they can change anything in the story, as long as they both agree to the change. We might even have more than one novel going at the same time, so if I was sick of writing mysteries, I could hop over and work on the romance novel for an afternoon.
We would build each novel incrementally. Each time my pair and I picked a story card to work on, we would say, “What’s the simplest thing we could possibly write that would make this work?” We would start with a simple design, and only add complexity as it became necessary to make the story cards work. By adhering to YAGNI, and constantly keeping the plot “as simple as possible (given the story cards we’ve accepted so far), but no simpler”, we would make it possible to work at a predictable pace.
And we would focus on keeping the novel in a constantly shippable state: trying never to end an iteration with plot threads dangling, or incomplete scenes. Even the first iteration would turn out a complete (if short, and possibly boring) story.
The more I think about this, the more I think it might actually work. (That probably means I need more sleep.)
The hard part would be writing automated tests to run against the plot, so we could refactor with confidence…