DS Log

Thoughts on changing systems

published

I was writing these notes for a future post, but decided to just turn the notes into an Actual Post instead. Apologies for the low effort in its formatting/editing.

  1. A system designed not to be changed can’t be changed according to its rules. You need to work outside the system to change it. This means you’ll be taking actions that conflict with the system’s assumptions, or that might deliberately not be allowed by the system. Understand the possible consequences, remediate the plan if those consequences aren’t tolerable.
  2. This also means you’re going to break that system. How you choose to break it is important.
    • In most cases, starting from scratch (with the original system running concurrently) is the most straightforward route. You might have to figure out how you’ll migrate the important parts of the original system into the new one.
    • In the trickiest cases, you have to break it and change it in parts until the whole is different, you can’t break it completely and start from scratch. This will usually happen if you’ve made availability (or other) guarantees that can’t be maintained if you choose to start from scratch.
  3. I haven’t found yet a system that has in its design a way to force the system to be open to many changes without breaking something else. However, it can have ways to incentivise being open to change, but then it’s up to all the people using the system to ensure the incentives are still valid, and enforce that malicious changes are rejected.
  4. Whenever changing the system, it’s important to understand whether the changes will make the system less open to changes in the future. By nature, humans won’t want to think too much about these things. This is the sort of work that requires a lot of hammock time, and thinking is Hard™. They’ll tend to close the system down, and then you’ll have to break it to change it in the future (see second point). However, trying to account for every future possibility leads to analysis paralysis and overcomplication. This is a tradeoff. I think the best option is to make sure there is at least one future option to change whatever’s being done to the system at the moment without breaking it. If you’re working on systems out in the public (where you might/will not have enough/full control over the design decisions), up that number to at least two future options.