Saturday, January 29, 2011

Using Software Development Processes When Writing Fiction

This evening I read a blog entry from one of my writing friends.  In her entry, she said as an aside that she has a word count goal for herself for the novel she is working on.  She had so many words written already and wanted to add 2000 words this week to feel productive and successful. 

On another blog I have been reading, the author, who is a published children's book writer, discussed setting writing goals as a whole - like setting a timeline for finishing an entire book.

Different things work for different people, but for me I have to approach writing as I would approach a project in the workplace.  I used to design and write custom software for use inside a large company.  As time went on, the applications got more and more complex and the methodologies used by our department became more and more important.  When we added more members to our development teams, we also started developing in a componetized manner.  For the normal, non-nerds among you, that means we took each functional piece of the application and developed them independently from the others but with the overall plan in mind (for only the nerds among you, of course, a functional unit can contain more than one component, but you know what I mean). 

For this process to be successful, we had to document the user's requirements rather thoroughly and come up with a general blueprint for the application as a whole and very detailed blueprints for each functional piece.  My boss expected us to map out every function call and parameter to extreme detail, almost writing the application in the documentation before a single line of code was written.  As a rule-follower, I did what I was told, but wasted a lot of time in that process.  The fact is, each developer on the team basically followed the blueprint but ignored it when they needed to.

Each person assigned to a project would be responsible one or more pieces (components).  Each piece was prioritized so the base functionality could be given to the end users quickly, with the extras added later.  Once each piece was completed, the lead developer would do integration testing, making sure all the pieces fit together.  If there were changes or errors, someone would be assigned to fix them while other components (like the ones that didn't make the first cut) were written. 

Now I have given up all that computer nerd fun and have decided to write novels.  While I haven't published one quite yet, I feel very productive when I treat writing a novel like a software development project. 

When I am in the planning phase, I might jot down a few notes, but usually I just think about the story when I have quiet time, like when I am in the shower or rocking my baby to sleep.  I think about it until it seems real to me, until I have an idea of who the characters are, what is going to happen, and the structure of the thing. 

Then I start writing (the development phase), either here on my computer, or more likely in a notebook at first.  I write one chapter at a time as if it were a software component. I write it until it is done.  If I have time, I write another.  But I never ever stop in the middle.  If I did, I would need to throw it away and start over, which isn't always bad but is kind of a waste of time, which I don't have lots of.  I write quickly and lose myself in it just like I did when I wrote software, although writing fiction is a million times more enjoyable.  I escape to places I create instead of simply forgetting the problems in my life by trying to fix the business process of the day.  In either job, this is my favorite phase.  I write without editing and without worrying about anything except the chapter I am working on.

I try to write iteratively, a few chapters at a time before moving on to the next iteration (several more chapters). Iterative development in nerd-land means you develop up to a point and then turn it over to the people who need it so they can see you are not twiddling your thumbs while they pay you.  In my writing projects, I consider this testing phase to be the pass where you type up what you hand-wrote, or get out your red pen, leave your ego somewhere else, and mark up the printed pages.  I know as a computer nerd I should be comfortable editing on the screen.  But I like to do it old school:  print it, make changes in ink on the paper, add those changes in the computer, print it again, get out the red pen again, etc., until I am reasonably happy it is good.  I do that with whatever chapters I have completed and then take that to my writing class, which is like user testing for me. 

Once all the chapters are done, I do what I consider integration testing.  I read the story, freshly printed, all over again starting at chapter one.  I check to make sure there are no errors I previously missed, but mostly check to make sure it reads as if one person wrote it in one sitting, that I didn't screw up names and time lines.  I do research when I'm uncertain, make changes, and do it again. 

I didn't plan to write this way.  I didn't map out my process, but realized after the fact that I have internalized the processes we used at work, which were very comfortable to me.  I can't believe my experience developing applications, testing applications, and doing project management simultaneously for several concurrent projects for more than ten years trained me to be a productive writer.  I never would have guessed it. 

In case you are wondering, yes, I did check. I have written about 9000 words of the novel I just started and added another 2000 tonight.  It was fun to add it up, but I feel better about just making sure I write one chapter at a time when I have an hour to spare (the exact time I need to write one chapter, strangely enough).

No comments:

Post a Comment