Forever change

Let’s start with a few updates about the blogs.

I’m going to be busier in the coming weeks so, for now, posts will only be once a week. It might be possible to go back to twice a week once things have settled down. We’ll have to see.

If you’ve been reading from the start you may have noticed the change in my code samples. They have gone from the default WordPress code block to CodeMirror Blocks. Hopefully they’re clearer. I’d like the option to present multiple language code samples, maybe a block with tabs, so the reader can choose a preferred language. However I’ve not yet found a WordPress block that would support this.

Who would have thought things would change?

The only constant is change

I’ve mentioned the consistency of change before. Indeed I’ve mentioned it… once, twice, thrice, four times, five times that I can see. So apparently I think it’s important. I don’t have a study to point to but it’s been my experience that it’s the case. The projects that I’ve been on have not normally followed a straight line. They curve from release to release under changing demands.

I can imagine projects that would follow a straighter line. At university I was taught about the waterfall model. It’s rigid phases of: requirements capture, analysis, design, coding and testing. I can see that with a specific requirement you could design something that was just right and stick with it, no further changes necessary. I’m sure these do happen.

However my experience is still that things often do change. Given a specific target platform of MacOS for my project and nothing else but, four years later, suddenly a Linux version was needed. So the platform might change, performance targets might change, interfaces might change, functionality might change. Even if no-one means for things to change they may change. Budgets get cut or increased, limitations in hardware or software dependencies are discovered, security vulnerabilities become apparent. Things change.

Planning for change

Given all of that you should try to plan for it. Of course you cannot know exactly what will change only that adaptability is useful. I got this post together quickly so this is some brainstorming. What can you do:

• Most projects have some parts with variation. Important numbers tend to be zero, one and many. If you have something with two options then consider setting it up to have many options. If you already setting up for two options then it can be an easy step to allow an arbitrary number.
• If you collected related code together and don’t repeat yourself then changes can be localised as well.
• Make use of tools that are available on multiple platforms. If someone has already gone to the effort of writing something that can do it everywhere then you won’t have to.
• Ideally choose tools that have long service history and active support. That’s not always possible but if not you might have to be caution in other ways.
• This sounds trite but don’t put all your eggs in one basket. If there are multiple projects running then consider using different tools just to gain experience with them. If there are problems with one tool, or maybe if it just turns out to be better, then you can switch.
• Use interfaces and wrappers to provide separation. This applies on all sorts of levels: in your own code providing an interface rather than a specific class, in using a library or web service using a light wrapper rather than direct access. Having a slight separation means you can more easily swap out for an alternate system.
• Spend time on interfaces between different systems and different times. Joins between different systems can be particularly difficult to change. It may mean negotiating a change between different owners. It may mean organising a simultaneous change on different systems or supporting multiple standards simultaneously. Thinking through the API beforehand is worth it. By different times I mean persisting information, saving files or databases. Here you cannot negotiate the old format it is what it is. You can make sure to have version numbers from the start, you can break the data into parts and allow for new data to be added, you can try to seamlessly load old files into new systems.

In the end

You won’t be able to predict all the changes, that’s part of the point. You can anticipate some changes and organise the project to make others easier. There is a cost, a bit more thought up front, but it can really pay off.