Posts Tagged 'software engineering'

Software Engineering Models for writers (part 2)

My previous post on this topic talked about how the writing process (or at least my writing process) is like the waterfall model of software engineering, in that there are discrete phases, each of which must be completed before the project is complete. In software engineering: Design, Code, Test; in writing: Plot, Write, Edit.

Waterfall isn’t generally considered to be a good model when it comes to software development, but for fiction writing it is generally seen as the truest and best way. You should Plot before you Write and must Write before you can Edit. I’m so deep into the waterfall mentality as a writer that it was hard for me to see how to make a parallel between writing and the Agile software development method.

First, a brief introduction to Agile. Agile software development means all sorts of things to all sorts of people. It’s a buzzword; it’s an umbrella term for lots of different software engineering methodologies; it’s new, hip and trendy; it’s all been thought of before… etc.

I have only been working in an Agile team for the past four to five months so I am by no means an expert, but I enjoy Agile, perhaps more in theory than in practice – because it sometimes feels like we’re still practising the practice.

To me the keywords of Agile are timeboxing, deliverables, and stakeholders. Setting a very definite deadline – creating a timebox, and committing to having something at the end of that time which is functional and deliverable to your stakeholders. The stakeholders then evaluate the delivered item and decide what they’d like to see happen in the next iteration.

How to parallel this software engineering model as a writing process? First, have writing iterations of a set length at the end of which deliver discrete units of completed fiction. By complete I mean written, edited and polished, and standalone. I had initially thought that a chapter could be considered a discrete unit of fiction, but I dismissed that idea. A chapter isn’t standalone and would be difficult to write without knowing the overall design and plot.

No, a discrete unit of fiction would have to be something publishable in its own right. So the first iteration would result in one or more flash fiction items, later short stories, a novella and eventually a novel. Fiction units would have to be strands of the tale, written without necessarily knowing how they would fit with the final piece. A fiction unit could be a storyline, a characterisation, a situation, a scene that works alone. Later in the process work items for a writing iteration could be to tie fiction units together, or add to existing units to make them more bulky and fulfil a story requirement.

That’s how I think I’d do it. As to the other ingredient of Agile – delivering to stakeholders, I’m a member of a reviewing/critiquing site called Urbis. People can post their writings there and have them reviewed by other people. Reviewing earns you credits and lets you buy more reviews from others. Posting a fiction unit on the site and getting favourable (> 7/10) reviews could be an exit criteria for each iteration. Once the units start to come together into something coherent and of a decent length I could try submitting it to be published in a magazine or similar. I’ll have to see how it goes.

I’m hoping that I’ll find a new way of writing quite freeing. I have difficulty with perfectionism and when writing in the waterfall model I tend to get depressed be the sheer mountain of ‘bad’, rough draft that I have to deal with in the Edit phase. I this Agile model my urge to tweak my writing into shape can be satisfied much quicker. Also writing fiction units and not knowing what the larger tale is until it’s toldĀ  feels like a much more creative and organic way of working than nailing everything down at the start.

Starting next week I’m going to try to create a work of fiction using this model. And the good part is – if I get downhearted, or distracted by new ideas, and quit half way through I’ll at least have something finished.

Software engineering models for writers (Part 1)

I’m a software engineer, and I’m a writer. One pays the bills, the other feeds my soul.

Generally I consider these two parts of my life to have very little to do with each other; however this evening I got to thinking how like the waterfall model of software development my process for writing a novel is.

The waterfall gets its name from the shape of the diagrams that demonstrate it. Phases of development follow each other without overlap, starting with requirements gathering and ending when the product is deployed.


When I set about writing my novel in progress for NaNoWriMo 2007 I followed, pretty much, this process. With a few tweaks.

Instead of gathering requirements I gathered ideas: scene ideas; character ideas; bits of inspiration.

Instead of designing I plotted.

I wrote prose instead of code.

Now I’m in the analogue of the testing phase. I’m reading and reviewing my work: testing that the characters are believable and consistent; testing that the plot hasn’t got any holes; testing that the novel’s themes work. This testing/reviewing finds bugs in the novel that I will have to fix.

Enough time and work spent in the testing phase and I’ll be ready to move on to the deployment phase. I’ll have a ‘finished’ manuscript ready to start sending out to publishers.


I would say that this waterfall model is one of the most common processes for writing, but in software engineering the pure waterfall model is thought of as a flawed way to do things. I’m currently working on a project that is following an Agile software development method. So for another post I’m going to give some thought to how I could apply a more agile approach to my writing.

What I’ve been twittering

Error: Please make sure the Twitter account is public.

What I've been tagging...

What I've been taking pictures of...

RSS What I’ve been listening to…

  • An error has occurred; the feed is probably down. Try again later.