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.