State-Machine Hate

“Quick, how many FSMs are there in your code?”
Zero, right?
(Yeah, I didn’t need to say “Quick” — you already knew the answer)

A better question might have been “How many places in your code could benefit from using an FSM?”.
This, one is a lot more discuss-able, with pro-FSM and anti-FSM camps getting into the usual thing (if you’re hankering for entertainment, grab some popcorn, and then ask a group of erlang devs about gen_fsm).

Rephrasing the question yet again into “How come there are no FSMs in your code?”, you usually get responses like “I didn’t need them when I started”, and “They’re too complicated”.
And now we get to the heart of the matter. Let’s parse these two responses

“I didn’t need them when I started”: We’re all trained to incrementally add behavior to our code, and, when you’re starting out, it just doesn’t seem like the system is worth the time, energy, and effort associated with using an FSM.
“They’re too complicated”: Remember FSMs in your CS class? Worse, in your Control Systems class, for you EE types? They were chock full of automatons, Moore/Mealy, Acceptors, Math, and whatnot. And yes, it was f**king complicated.

We have mostly been trained into perceiving them as too complicated, which ensures that when we are starting out with a new project, we do not use an FSM. After all, we want to start simple, right? And FSMs are complicated, right? And by the time the project warrants one, well, it’s way huge, and who wants to refactor all that stuff?

The thing is, they are not complicated. All that stuff in CS class? You barely use most of it — you’re basically looking at states and transitions (and, given that most languages have some level of first-class tooling supporting FSMs, it is really easy these days (•). On top of this, you reap huge benefits in your code, in terms of clarity, auditability, logging, upgrading, isolation, and a whole bunch more.
And yes, you did need them when you started, you didn’t realize it. Or maybe you did, but had a little bit of “Who wants to think through all the states of the system up front” going on, which is far more likely. After all, thinking through stuff before coding? Ugh.

So yeah, learn to love your FSMs…

(•) Check out Fred’s excellent chapter on FSM’s for how erlang does it.