The project does not seem to be maintained anymore though :/

How to recognize a state machine pattern?

• a state or status boolean flag
• boolean fields such as published or paid. Also timestamps that can have a NULL value like published_at
• a record that is valid for a given period in time

Then the transition history has to be kept. At some point the transition history will be an invaluable source of information. The simplest way to keep track of the transitions is to add a timestamp field for every possible state. However, it is often possible to revisit the same state multiple times. In that case, simply adding fields to your model won’t do the trick because you will be overwriting them. Instead, add a log table in which all the state transitions will be logged. Fields that you probably want to include are the timestamp, the old state, the new state, and the event that caused the transition.

Instead of removing an object, add an error state for any reason you would have wanted to delete a record. A spam account? Don’t delete it, set it to the spam state. A fraudulent order? Don’t delete it, set it to the fraud state.

Why?

• We don't need one until we do

  • you almost never create an object fully formed with all the behavior it is ever going to need
  • when it is complex enough, it costs too much time to replace it with something that has equivalent functionality

• the state machine is a fluffy bunny

  • there is the belief that state machines are more complex than they actually are
  • it is therefore nothing but pragmatism that makes us consider a “full-blown” state machine overkill.

BUT most state machines you’re likely to need in your day-to-day development have nothing in common with their computing theory counterparts

• Adding a state machine library has a learning curve. It is rather small.

So moving to a state machine:

• Integration is painless but moving all the code around to be inline with state machine is a big pain
• Using it from the start is a breeze, as such as future changes.
• We’re now able to easily introduce more states to give our users extra information as well as allow us to track things to a finer grain.
• Return values from state transitions are 100% consistent. There are no strange objects, arrays, nil, boolean depending of the developers.
• It is easy to log
• Refactoring lead to greater code quality with state machines

We seem to shy away from state machines due to misunderstanding of their complexity and/or an inability to quantify the benefits