OK, this idea really betrays my software development roots, but it was half suggested by Alex McGivern after an offhand comment that I made on Twitter a few days ago. I think the idea in principle seems sound enough to discuss further.
In software development there are various different development methodologies. You don’t need to worry about most of them, or even exactly what a development methodology is. The information is on the Internet already, and I don’t really feel like dragging up first and second year computer science stuff so can parrot it. You just need to be aware that there is a set of techniques which are broadly called “agile.” These are techniques used by programming teams working on large enterprise level projects to try and produce higher quality code.
One general characteristic of these methodologies is that they are test driven. In software development this means lots of seeing if the various components of a program or website behave as expected. Yes I am simplifying, massively, because I don’t want to get drawn into the minutiae of software testing, which is rarely an interesting subject. But anyway as a writer I test my prose. How do I do this? Well I often send work in progress material to people I know via email and ask them for feedback as I find useful for me to be able to calibrate my expectations of a piece with other peoples’ opinions.
That brings me onto the next major part of agile software development which is short cycles of development. The process of writing software under an agile methodology can be simplified to be the cycle of: planing, developing, testing and repeating until as most of the functional requirements of a program have been reached. Well this is a useful method to apply writing. I’ve always been under the impression that it is a good idea to have a plan when writing anything, but my experience has always born out that it always best to be able to go back and revise that plan according to the results of various “tests” I’ve carried out on my prose.
OK, so I’ve not really given a single idea here. I’ve pretty much outlined my process of writing by badly applying the metaphor of agile software development. Well I should add a social element here to add something new. So in Extreme Programming there is also the idea of pair programming. The idea that two people sit at the computer and one of them types the program in while the second person is there to point out any errors and review what has been typed into the development environment. These roles are swapped after a short period of time like, let’s say, that magic half an hour time period).
Of course these two programmers are working on one project. They are also likely to be part of a much larger effort. This workshop idea isn’t really about doing that exactly. Although it would be fun and interesting to try it out; even if the number of stabbings in Leicester would increase one-hundred fold.
Let’s take these ideas and do something with them now. Well this idea of pair programming is rather useful. It provides a simple arena for constructive criticism, and it also gives us a time limit in which to drive efforts into. As an unsourced statement I’m going to say that working within well defined understandable time limits increases productivity.
So we can have two writers working on their own projects in the same room for a length of time. I’m going to say the length of an music album just to make this more social. And at the end of that time the two writers exchange what they’ve been working on and test each others work.
This means the writers read what they were given by their partner and then provide some criticism. In the next looping of this method those criticisms can be taken on board by the writers and folded into their work, and then they can produce more stuff. Then, well, what’s produced is critiqued and the cycle repeats again until an agreed end point.
I reckon that this could be done via the Internet. Although like many writing activities having other people around you can help provided some peer pressure to get shit done.
This idea is quite a bit more fuzzy that the Kick School of Creative Writing. It’s more a general technique than a workshop to help people get better. But let’s see where this idea might go. As always, the goal is always better prose.