In which I explain flawlessly how the principles of software development can easily be applied to the process of developing a story…
Those of you who follow me on twitter (which probably accounts for everyone reading this) might remember that I started a new job about six weeks ago: Software Development Team Leader. The job title pretty much explains itself, but one of the first tasks I set myself was to completely rethink the way my team goes about software development.
It’s still a work in progress, and probably has plenty of room for improvement, but the basic process goes like this:
Sorry about the teeny, tiny text – obviously legibility hasn’t been factored into the requirements yet…
Since you’re not here to read about software development I’ll only go through the above diagram in the briefest terms. The main point is to plan everything before you start writing a single line of code: you work out:
- what the application needs to do (Requirements);
- the particular things it needs to do (Feature List) in order to satisfy those requirements – you could think of this as shopping list, if you like;
- from the Requirements and Feature List you compile your Specifications (‘if someone opens this page, this thing should happen’ etc);
- you then work out how it’s all going to fit together (Architecture);
- finally you build it and test it – if something goes wrong you either fix it or, if it’s a biggie, you go back a few steps and revise your Specifications
I’ve been going back and forth over this process during the past few weeks, but what finally made me realise I was on the right track was the thought that the same process could be applied to story writing.
Take a look at this:
I’ll go over this one in slightly more detail:
- Reason – why are you writing this story? what function does it serve? who is the audience? This should be your motivation for writing the story in the first place;
- Plot Points – again this is almost like a shopping list, think of it as the things that need to happen in your story, the particular scenarios you want to convey, possibly broken down into chapters;
- Characters / Events – this is where you use your plot points and motivation to put together a framework for your story. This is not the plot, this is where you work out things like why Character A reacts a certain way when Character B starts wearing women’s clothes. It can be character backgrounds, timelines, relationships – all the background material that will inform the plot and help you work out how your characters fit into the story, and what they’re going to do there;
- Plot – this is probably where a lot of people actually start, but this process will be a whole lot easier if you’ve already gone through something like the above three steps. Needless to say, this is the part where you work out the plot of your novel;
- Write – yeah, we finally got there. Once again, if you’ve done the first four steps (or similar) the writing process should be a lot more pleasant and, ideally, a lot quicker – you’ll already know what a character’s doing at a certain point, and why, and what they’re going to do next, so you can focus on the writing itself;
- Read – shouldn’t have to explain this, but proof read everything you do for spelling, for grammar, for plot holes, for inconsistencies, for anything that’s not right. Hopefully if you’ve planned properly this will be a routine tidying exercise (in which case a mere Rewrite is needed) but if something more fundamental is wrong you’ll need to go back a bit further (and Rethink).
You might have the same reservations about this process as some of my development team do: mainly the perception that it extends the development time significantly (and thereby delays the actual delivery of the story/application). Admittedly I have yet to put this development process into practice, but I have a strong conviction is that this level of preparation (comprising the first three to four stages) makes the eventual writing (or coding) stage not only easier, but quicker. It also reduces the risk of encountering serious problems at the proofing stage which, in the end, means you can probably deliver the final product a lot sooner.
I’m going to try applying this process to the next story I write, and I’ll let you know how I get on (complete with notes). I’d love to hear thoughts from any of you fellow writers (or software developers for that matter!).