Pages

Thursday, 10 April 2008

Scribecraft - Part 2: Overview

This section provides an overview of the whole methodology. Later sections will explain each of the different parts in more detail.

The methodology is iterative and comprises of six phases. Central to the methodology are the activities of planning, scheduling and testing.

Iterative

We carry out the six phases not necessarily one after the other, as we might in some traditional cascading or "waterfall" methods. Instead we blend them together in amounts that are appropriate to which particular activities we're doing, and where we are in the schedule. Having said that, the emphasis does shift progressively as we go around the cycle.

An advantage of this technique is that it helps us to lose the fear of going back and changing something more fundamental, should we discover a fault in a "later" phase. Even the planning and scheduling aspects can be adjusted as we go along.

We can go around the cycle many times if necessary, evolving and improving things as we go.

Six Phases

In later sections I'll deal with each of the six phases of the methodology in more detail. For now here is a summary of them.

Requirements

This is basically defining what the end result should be. The poem, story, novella, novel, three volume epic, or whatever it is. The product, if you like.

Specification

This is for defining in more detail what kind of product you are going to produce. Genre, style, format and scope.

I've also included research in this phase, though some authors may prefer to have research as a completely separate phase in its own right.

Design

This is for mapping out the content of the product, including things like plot, characters and storyboards. It can also define the structure of the product, such as parts, chapters and sections.

Implementation

Here we have the actual writing part. Putting the thoughts, ideas, plots, characters and stories onto the pages. Note though, that implementation is much more than just typing and editing. There are also many other activities such as experimentation, illustration, exercises and note-taking.

Building

This may sound trivial but from your implemented artefacts (documents), you need to build the full product. This may be as simple as printing out the document onto paper. It may be much more complex though. For example, you may have a master document that is built from several smaller documents. There may be drawings or other graphical material to incorporate. You may need to construct web pages from your source material.

Deployment

This is where the product is deployed to its intended audience, or to a literary agent or publisher. This can be quite complex, depending on the requirements of the recipients (and the authors). There may be strict rules and processes to follow.

Deployment can ultimately be paper-based but also be to electronic media such as web sites and blogs.

Planning & Scheduling

Planning and scheduling are at the core of this methodology. Without them there is likely to be chaos for all but the very smallest projects. Every aspect of the project should be planned and then scheduled. Please note that you don't have to do all of this planning up-front. The point of the iterative approach is that the plans, schedules and actual product can evolve side-by-side.

Testing

There is a very appropriate quote I once heard. It goes something like "computer software need reviews for the same reason that pencils need erasers". The point is that without testing, the quality of your product will not optimal. In fact, the quality may not even be determined!

Have you ever written a piece, given it a quick once-over, got a friend to read and check it, then submitted it for publication? Well, at least you did some testing. In this methodology, we often take testing to extremes. We test everything that we can possibly test, which leaves almost nothing out.

In fact, we can write the tests before we write the documents. More on this in later sections, but suffice to say for now that the methodology is a highly test-driven one.

6 comments:

Annieye said...

I seem to remember learning something like this in my ICSA exams, which I sat about 10 years ago. It was in 'Information Systems' and then in the Professional Exams in 'Managing Information Systems'.

I was part of a team that helped introduce Anite to KBC. I tried to use Anite for committee admin, but it didn't work. It failed dismally at the 'testing' stage and I abandoned it when we got Jadu, which did the same job via the website. If you have a look at www.kettering.gov.uk at the meetings and minutes you'll see what we eventually did to archive agendas, reports and minutes.

I think it's very clever of you to assimilate systems development with writing a novel. I'd never have thought it could be applied to writing a novel in a million years if you hadn't suggested it, but I can see from this post that it most definitely does!

You old clever clogs.

Denise said...

Wow, feeling a bit bewildered after reading that! Definitely feel I skimped on the specification and design elements of my book, which I'm paying for in re-writes now! Really got me thinking about next time though. I find it really helpful to see everything when I'm trying to plan and may get a giant whiteboard to help divide things up.
Very interesting, look forward to the next post.

Lane said...

I'll be taking all this on board. Like Denise I'm paying for lack of planning by drowning in the re-write.
I need to digest all of this though. It's not something I've ever really paid much attention to before.
Thanks Kev:-)

Fiona said...

There's a lot here for me to take away and think about. I definitely agree that planning helps. I know I'd get lost without it.

womagwriter said...

Aarrgghh have been doing this all day at work on a course, I come home and start browsing your blog and find more of it!

Captain Black said...

Sorry to foist more "work" on you, WomagWriter. Welcome to the blog. Seen you on Novel Racers somewhere, I think.