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