Creative writing and software development (part 3)

I read an excerpt from a book by Patricia Highsmith – I don’t know exactly from which one (I read it in an anthology), but I guess it was Plotting and Writing Suspense Fiction. She repeats the notion that good books write themselves (see Creative writing and software development (part 2).) One guideline she gives is, as you write the first draft, to never forget to pay attention to the whole; to remember to check how the events fit into the bigger picture.

This is definitely an important lesson for programmers, too, and I connected this with the only project I have been in where a very long time (almost a year) was spent on analysis and design. We managed to create a design where a handful of elements were repeated again and again at different scales. If you were to visit a place in the code for the first time, with experience from other parts of the system, you’d find familiar elements and instantly get a sense for how things worked.

Highsmith also writes about the importance of clearly sensing that the project is going somewhere, that you are constantly accomplishing things. As a programmer, I have been in several projects that, at times, seemed to stand still, going nowhere.

Then I read an article on soap opera writing. I’m interested in the process, because I feel that they are “naturally agile”. In software, process has become either non-existent (as in: no-one reflects on it) or too emphasized (as in: we do lots of things because the process says we have to) – and as a reaction to that, agile processes have been invented, from the basic ideas that you should only do things that have significance for the end product; that you should try to adapt the process to be as friction-less as possible; that what’s important is doing.

In soap operas, there’s a team writing the scripts. According to the article, you have one or two head writers, four to five storyline writers, two editors, and five to ten episode writers. The head writer creates the overall story, which is probably fleshed out by the storyline writers. There are many meetings where the scripts are read and discussed, after which they are revised. The editors judge what works and what doesn’t. Then the episode writers get an overview for the season, along with character descriptions.

Lastly, I read an interview with Swedish writer P O Enquist, where he contrasted inventing a zipper with writing a book. When inventing a zipper, the problem domain (to use programmer speak) is fairly defined: it’s about joining two pieces of cloth in some way. In writing, you actually doesn’t know what you are going to invent (which may be more true for some writers than others). To me, software development seems to fall somewhere in-between: although you know roughly what the software is supposed to do (or what problem it is intended to solve), there’s much to learn about the problem domain. While some writers chuck out a book a year, others release books very sporadically. Is it possible to estimate the time it takes to write a book, even if you are a one-a-year writer? Does he or she know that it will be finished by the end of the year?