Payment State Machines Are Not Cyclical

If your diagram is going back to a previous state, you're doing it wrong

Nothing in nature is infinite, and software that pretends to map it shouldn’t be either.

Despite that, almost all state machine diagrams I’ve seen have some loop built into it. It’s as if, over time, we’ve noticed that there is some notion of “start again” in every domain, and the best path forward we’ve come up with to model that behavior is to go back to square one.

Complexity ensues. Because, in reality, it isn’t back to square one. It’s something else.

Is a baseball player who bats again playing the same match over and over again? Is someone who proves a hypothesis wrong bringing back science back in time?

Is a payment that gets declined a waste of time?

I’m not trying to get philosophical here: software products emulate transitions in state, and we almost always end up using an artifact (the “loop”) that fails to capture what’s really going on.

Perhaps it’s the obvious path forward, and by the time the code becomes unmanageable, you can’t tell where you made the mistake in the first place.

It represents a quagmire which starts well, gets more complicated as time passes, and before long entraps its users in a commitment that has no clear demarcation point, no clear win conditions, and no clear exit strategy.

— Ted Neward, The Vietnam War of Computer Science

This is The Payments Engineer Playbook, and I’m Alvaro Duran. This week, I want to dive a little bit more on why you should avoid state machines, because lots of people had opinions about that article.

Why Payments Engineers Should Avoid State Machines

On the one hand, I have to apologize: state machines means different things to different people, and I wasn’t specific enough about what I meant by it.

But on the other, the feedback that I received from it was founded on the premise that state machines is as close as engineers can be to mathematically prove the correctness of software, and that avoiding them meant chaos and anarchy.

Nothing further from the truth.

State machines could be the right choice—if people built them properly. Which they almost never do.

In this article, my goal is to spell out not only why cyclical state machines make software more complex, but also how to build state machines that work much better.

Let’s dive in.