Developing Programmers .com

There are several ways to think about software, and it can be useful to consider your software from a few different perspectives.

Object oriented designs can help keep you grounded in what real things your code is representing. Functional approaches (even just in a spec) can help you keep clear about a problem and it’s constraints.

Today I’d like to bring your attention to the perspective that software is a state machine.

In an object oriented program, you can fairly easily imagine member variables in a class as defining state, and methods as state transitions. This model works well in self contained programs. It gets a bit tricky when the state transitions have complex side effects or dependencies.

I’ve been working on large systems that share state across many diverse subsystems, often over a network. The system even manages the installation of other software, according to the state we keep in our database. So updating a partner website with an added user or installing software based on adding a project are examples of states having dependencies that need updating whenever the state changes.

What many people do is code these state based dependencies as “side effects” of state transitions. I can see why – they know what action they want performed and the state transition tells them when it needs to be performed. Easy.

But, this isn’t the most reliable approach. What happens if the network glitches? Or the third party system is down in that moment? You end up not pushing the current state to that system. Worse, if the system doesn’t notice and correct its error, the mismatched data propagates and can even become worse over time, triggering further errors because the dependency is not starting in the state you expect.

The solution is not very difficult.

Do your core state changes as usual, but for dependencies write a kind of “refresh” function instead. This should make as few assumptions about the dependent systems as possible.

In our example, our refresh functions take a look at the actual software installations and take whatever steps will make the installation match our database. If a server is down, we’re already ahead because the next state change will take a look and correct any missing installations. But it gets better. We now have a function that’s safe to call at ANY time, so we can trigger that ourselves if we fix a bug or a sever that was down comes back up.

One simple example of this is a web browser. It updates it’s display when you visit a new URL. But if anything goes wrong you can hit the “refresh” button and it’ll have another go at establishing the consequences of it’s current state (the URL field).

It’s not difficult but this simple principle can make your software a lot more robust. You just need to gear your methods around re-enforcing a state rather than focussing too much on the state transitions. I call this approach “strongly stated” software.