As you say, state machines are the best thing around.

As for the "paid" and "delivered" _states_ in relation to paid_at and delivered_at timestamps. You can have your cake and eat it too.

> As you say, state machines are the best thing around.

Pretty sure that's not what vemv said. Trying to put words in their mouth is very much not cool.

100% this! One of the worst projects to reason about I have ever worked on (and I have worked on a lot of trash) was when a colleague insisted on implementing a state machine in a system that tracked voucher (offer) redemptions. State machines do have their place but coordinating business logic with one is a bad idea IMHO

This same colleague had implemented a similar FSM (flying spaghetti monster as known by the team) in an FX (foreign exchange) platform at a previous company. Which after a job change I got the pleasure of experiencing, nobody in the team knew how it worked and everyone was petrified of making changes

You realise you're allowed to use more than one state machine right ?

Sure, but as soon as you create linkage between them - if the state of machine A affects what transitions are possible when in machine B and vice versa - then you don’t really have two state machines, you have a single Cartesian state machine combining both. Or you have a pair of metastatemachines which aren’t able to be analyzed in the same way as an independent state machine.

It’s like the difference between solving a maze, and solving a maze with constantly moving walls and traps in it.

Yes. From intuition I'd say that getting the right granularity is just as hard as getting other granularities right (e.g. how "micro" or "macro" your services should be).

In the end I don't pursue an absolute truth. Things are often gradients, one can pick whatever tone seems more reasonable.

This was my thought too, I hear most people get a bit jumpy when they see two state machines, like its too many moving parts.

I think the issue most of the time is that you only start with two states, and you can avoid complexity by not implementing a FSM.

But suddenly requirements change, and you have 4 or 5 new states that could go back and forth. The original approach ends up being way more complex than implementing a FSM in the first place; or even, than implementing the FSM when you add a third state.

This "suddenly requirements change" is why I get instantly wary whenever I see a boolean column like `completed` in a design.

Sure, you start with two explicit states. But then you add `deleted` and now you have four states, whether you know it or not. Then there's talk of adding a third boolean column, and folks are wondering what it _means_ to be "deleted" but not "completed" and whether that is a valid state, and pretty soon the team is reinventing the concept of a state machine without any of the vocabulary that makes it straightforward.

When they seemingly need go "back and forth" I typically consider it good timing to create a new instance (object, or DB row) instead of keeping mutating the same instance.

e.g. one can consider a re-purchased return simply a new purchase, instead of doing a purchased->returned->purchased transition.

Yeah or even more insidious when a new state looks like, and so is modeled as, just a special case of one of the original two. As a mentor said to me early in my career "every functioning business system is a state machine, but the only ones that are easy to work on are where they knew that from the beginning."

Most systems I've worked on end up with one of the "original" states being a catchall or misc type entity that could carry any number of other meanings depending on timing and context. A lot of legacy code work in my experience is actually a game of "find and name the states" when they're spread out across multiple systems, written at different times and with different understandings of the broader system, and with different methods to track and modify them.

I worked for a department of motor vehicles (it also included what other states would call "the highway department"). I argued that the vehicle registration process needed to be implemented as a state machine. Other folks started "getting it" when I compared it to traffic lights. Certain steps had to be done in legally mandated sequences which were governed by state & federal laws as well as federal regulations. Like, the VIN must be checked with NCIC to ensure that it isn't stolen.

This used to be one of the states where dishonest people would "launder" salvage titles to remove the brand. If a vehicle is totaled (flood damage also counts), the title gets branded with the word SALVAGE. Every subsequent title for that vehicle should also have SALVAGE written on it. Before you can get a license plate for such a vehicle, it needs to be inspected for safety.

The human-readable diagram took up an 11"x17" piece of paper.

> For instance you could write a FSM that transitions from "paid" to "delivered"... or you could have two columns, paid_at and delivered_at, and consider those two columns orthogonal.

The first seems to imply that delivery cannot occur until the state 'paid' has been reached, while the second contains no such implication. Either might be correct, depending on how the business operates, and modeling the states and the allowable transitions between them is an excellent way to find out what questions need to be answered before you can produce a correct implementation - better in every way than implementing what seems right intuitively, and then seeing what happens.