Month: October 2014

Back to the Beginning

I feel like I have been blocked on Song for months.

I think it’s only been a few weeks really, but I’ve made pitiful progress on the third act. I keep thinking I know where the story is going, but then I sit down to write and I end up not knowing how to continue.

Part of this is being discoonnected from the story, part of it is not spending enough time in the seat on that story, but there is a large part of it that is frustration that the early chapters are just wrong now – I’ve made enough progress on understanding how the story fits together on the early parts that I feel I need to go back and fix things up.

Which is what I am going to actually do, since many of those early elements need to be laid down so that I can refer to them later in the narrative. I feel like making the story already written match the outline notes will help me to continue the story later. It might also help to get me into the more dynamic form of the protagonist.

So, back to the beginning.

Leave a Comment

Why Software Is Interesting

I identify as a writer of both fiction and code. Most of what I post about here is on the fiction side of things, but I wanted to write about why I still work on software*.

Deliberate Complexity

Did you know that software is one of the most complex artifacts that people make, possibly the most complex?

I’m not referring here to number of components, although I could – the number of lines of code in a piece of software can easily be in the millions. I mean that the elements of a program are deliberately distinct and interact in surprising ways.

Consider a bridge. Bridges are interesting structures which have to be made to deal with the specifics of the locale, but how many distinct components are there? Lots of girders, cables, rivets and bolts; road surface panels and railings. Lots of parts, but how many types of rivets? Three? Plus two kinds of cable in different lengths, cable anchors, four or five railing components… there are hundreds or thousands of parts in a bridge but a tiny fraction of that number of distinct components.

A lot of physical engineering design is making standard components that can be used consistently**. Software is written to define the minimal subset of components that will capture all the behaviour of the system – the things that make up software are as different from each other as possible, and big systems can have hundreds or thousands of unique components.

Now consider the interactions between those components.

Sane software design minimises the communication between components – this is called loose coupling, in the jargon – but even the best-designed code may act strangely. Sometimes design decisions are made which have no impact at all in the original context of the decision, but can have enormous consequences later on. How about a C++ compiler that launches a web browser? Sounds bizarre, but what was a benign effort at reusing a common library in the normal case became a complete system lock-up if you were trying to compile multiple files at once.

These kinds of weird interactions happen occasionally in physical engineering (just look at the Tacoma Narrows bridge, for example) but they happen all the time in software. They are bugs of course and as such shouldn’t happen, but it’s the nature of this absurdly complex system that they occur.

I sometimes gasp in amazement that computers work at all.

There Is No Physics

Another interesting aspect of software is that there is no practical limit on what your program can do***, so the actual constraint is on what the program should do. A great deal of good software design is figuring this out, and it is akin to finding the plot and the characters for a novel. Doing this analysis comprehensively is enormously expensive and so ends up only being applied to safety-critical or inaccessible systems. NASA does this exceptionally well, for instance.

The current state of the art in making software good enough but cheaply enough to be affordable is to use agile methods: this is like driving a car where you constantly adjust course or react to road conditions, but the feedback you get is from user reactions. It’s not perfect, but it’s effective.

In Conclusion

There’s a remark I’ve heard attributed to Alan Turing while he was building the first programmable computers**** that once they’d built the hardware then writing the programs would be easy. If programs had stayed as tight little balls of mathematical theorems then this might actually have been true, but as computers grew in size the programs they could run grew in complexity faster still.

Put simply, software is interesting because it is hard.

[*] apart from the risks of switching careers.

[**] none of this is to denigrate physical engineering – there are a lot of very interesting problems in engineering. Indeed, you’ll note that I don’t mention software engineering because I don’t feel that software is yet rigorous enough to deserve that label.

[***] ignoring for the moment such things as computability, problems with no algorithm for solution, and things that are generally hard.

[****] although I can’t find a citation, so it may be apocryphal

Leave a Comment

NaNoPreMo 2014: What To Write

Last year’s series of posts for NaNoWriMo prep (idea, characters, setting, outline) are still applicable but they were generic process posts. This year I am going to be writing a bit more personally about my journey towards November’s literary frenzy.

I say that because I am still not completely sold on the idea of doing NaNoWriMo at all.

Last year was a good one. I wrote a 100k manuscript from a decently structured outline, ending up with an interesting story (albeit a bit rushed at the end).

This year I come into October in a far more perilous state: I am half way through a draft that I would like to finish before November, and I have no idea what I would write for the month anyway. My rate of word production for the draft has fallen to absurdly low levels, and I have ever-growing piles of non-fiction commitments that could still torpedo all my writing in October.

So, I am going to start this prep season with a slightly different focus on figuring out what exactly it is I am going to write and how.


I have several options for the story:

  1. continue with the Song draft. If October goes as poorly for fiction production as September, this may be the most expedient thing to do.
  2. rewrite my apocalyptic superhuman story. 2006 was the closest I have come to not finishing NaNoWriMo, and I’ve known for years that the way I was telling the story was just wrong. Starting again with a different focus would help a lot, I think.
  3. the sequel to an early story. I have a pretty decent starting premise, a protagonist and antagonist, and even some thematic elements.
  4. a story about mortals in a world of immortals.
  5. about ten other stories in various states of completion and staleness.


Usually, I would say I will just write a novel and have done, but I am wondering about changing the structure a bit this year – perhaps a series of linked short stories would be interesting.

I’ve never done much with short fiction – the stories I write tend to explode in word count after the initial scenes – but I like the idea of having multiple beginnings because it gives me lots of options for starting the writing.

Some of the story ideas I have would work better in the linked story form than others, particularly the apocalyptic superhuman story. Any story with a single point of view character is likely to be better served by a single large narrative.

What about a series of stories whose point of view is anyone except the protagonist? I’ve seen that done occasionally with established series, such as Doctor Who episodes “Love and Monsters” and “Blink”. It might be a good fit for a couple of these story ideas, particularly the Manx Connection sequel and the superhumans story.

I am definitely warming to the linked short story approach.

And if it all goes pear-shaped I can always go back to writing more of Song.

Leave a Comment