Writing Is Like Software Development - Issue Log

In an earlier post, I explained how I have been a productive writer lately by using the skills I used as a software developer and how amazed I am at the similarity in the two processes. 

I recently finished polishing almost to perfection the first eight chapters of a children's book and typed the first draft of the last twelve chapters.  While I technically have a sense of completion, my work is definitely not done.

My story spans from spring until winter and has one significant flashback that spans chapters.  I need to make sure there are no anachronistic moments in the book and no confusion over the timeline for the eight year old crowd.  For example, at one point I wrote that days passed, but really weeks had to pass for the story to make sense.  I also need to make sure that fireflies are actually possible in the chapter where the kids catch fireflies - otherwise, I need to adjust the starting month or the number of weeks that elapse up to that point. 

My natural solution to tightening up the timeline among the twenty chapters was to attack it like I would do a code review.  I read each chapter, specifically looking for text relating to time or dependent on time (like the blooming of a particular flower).  I highlighted those lines in the printed copy (you could do this in your electronic copy, but that would drive me nuts).  Then I created a technical document detailing the timeline in each chapter the way I would document dependent components in a software application.  I noted the timespan in each chapter (like whether it lasted one morning or three days) and any references to previous chapters as well.

While I was parsing through the details of the story, the next logical step was to do an issue log.  I documented anything I needed to research, like the day those fireflies would first light up southern Ohio skies.  I also noted any other changes I noticed I needed to make or research, whether they were related to the timeline or not.

My kids laughed at me for doing an issue log for a children's story, but my techy husband thought it was brilliant.  Editing my own writing is much less painful if I put a process around it.  Never once did I have a negative thought about needing to make changes.  For me, finalization of a long piece of writing really is similar to finalizing custom software.  Once the application is functioning, it always needs work if it has any complexity and inter-related parts.  There's no way anyone will get it 100% perfect on the first pass.  Testing and rewrites are just part of the job. The same is true for writing - coming up with the story line and actually writing the first pass is a huge feat, but the perfection of every line is really the hard part and what will make an OK story really wonderful.

For me, the issue log is a time-saver and gives me control over the changes I need to make and any research that still needs to be done - whether the log is related to an application or a pre-teen chapter book.  All in one document, I can note anything I am not sure about so I can deal with it later.  I have control, and it feels great.  If there is any interest, I can post an easy-to-use version here later.