The Change Cascade

When you first develop a piece of code you generally do the best you can to make it fit for purpose and work in a flexible way.  Then, later on, you might need to come back to the code and change things to work in a different, or even more flexible way.

A good example of that for me is the changes I’ve had to make to support translations of the Quoll Writer website.

After doing some research there were a number of best practices that I decided to implement, the most important one is to identify the translation via an ISO language code embedded in the URL you use to access a page.

For example, at the moment the downloads page for QW can be found at:

This, of course, will serve the English version to the user.

Now, if someone creates a Polish translation of the QW website there needs to be some way of them accessing that translation and the server needs to know what translation the user want to view.

One of the recommended ways of doing this is to embed the language code at the start of the path in the url, thus:

Pretty straightforward, for a German translation you would use:


and so on…

The server examines the url requested, sees a language code and returns the translated page.

But the problem is that the code that serves pages to the user had no concept of these languages.  It was never designed to handle multiple languages or to examine urls in this way.  So begins the change cascade.  Just adding these two letters to the front of the url path requires a long list of things to happen, and for each “thing to happen” I need to make a change, with one change cascading onto another and creating implications and changes of its own.  It’s like watching an ice crystal grow.

So why am I telling you all this?  I realised long ago that creative writing and writing computer code are very similar disciplines.  They are both more art than science, they both require creativity, they follow similar rules, they have similar structure.  Change cascades also happen in creative writing, you make a seemingly minor change that then tumbles through the rest of the story, creating implications and forcing modifications, modifications you couldn’t possibly foresee at the outset.

The lesson here is not to be afraid of the change cascade.  Don’t cling to something you know needs to be changed just because of the changes it will cause.  If you know a story will be improved by the change then embrace it, make the change, then get to work.


Getting a case of Developer’s block and what it taught me about Writer’s block

We’ve all had it, sometimes we just don’t want to move forward or worse still, know how.  But did you know that you get it in all walks of life?  It’s not just a problem for writers.  Sometimes you get stuck thinking about a problem or avoiding the problem altogether.  How many of you have avoided that difficult conversation or the annoying task?  It’s writer’s block, just manifested in a different way.

Recently I’ve suffered with a case of Developer block.  I had a technical problem to solve that I just didn’t want to tackle.  Creating version 2.6.5 of Quoll Writer was extremely painful for me.  It was repetitive, technically frustrating, repetitive and tedious.  It drained my mental resources and even a long-ish holiday to New Zealand only partially helped restore me to “normal”.  In the past few weeks, apart from releasing bug fixes for QW, I’ve been working on an update to the User Interface translation editor to support creating translations for the QW website.  However I kept getting stuck, I kept getting Developer’s block.  I knew what I had to do I just really, really didn’t want to do it.  I would make any excuse I could to avoid it, “I’ll just do this first”, “I’m too tired tonight”, “the kids have been annoying me today”, “I’ll play Witcher 3 for a bit”, “mmm biscuits…”

Growing increasingly annoyed with myself (sound familiar?) I thought about what was actually blocking me.  What was the task I was avoiding like it had a terminal case of leprosy-black-death.  After some introspection, I realized I was avoiding making the Quoll Writer desktop application interact with the Quoll Writer server.  The application needs to make a request to the server to get the English strings that act as a base for all the translations.  It’s not trivial to implement but it’s not difficult either, however it is fiddly and tedious.

With the problem identified the block disappeared, I had identified exactly what I needed to do and why I was avoiding it.  Instead of the problem being a vague miasma lurking just beyond my reach I had given it shape and form and, more importantly, given it a clearly defined boundary.

So how does this relate to creative writing?  To me, the problem of Writer’s block is the same as Developer block and the solution is the same.  Identify the problem, define it, give it a form, a shape, a boundary.  If you have to write a difficult dialogue scene then plan it out, give it form and flow before tackling the details.  If you have to write a descriptive scene then maybe draw the geography or thing you want to describe.  The important thing is to identify exactly what you have to do and give it a boundary.  Know thine enemy.

But wait, there’s more.  You see thinking about this problem helped me realise that I always dislike doing server interactions for the QW app.  This isn’t the first time I’ve had this type of block.  But now I’ve identified what I dislike doing I can plan for the future.  The next time I have a server interaction I can detail exactly what I need to do and plan for it, I can give in a boundary.  In my own writing I often dislike and avoid descriptive scenes.  I love me some Tolkien and that guy could describe for his country but I’m not Tolkien and I need to know what I dislike doing to be able to give it form.  So, the next time I have some writing I know I’m going to avoid, descriptive or otherwise, I know what to do.