[steve_adams_86]

Early in my career I remember being really bothered by a guy who insisted we use a finite state machine for handling some stuff I’d already written and was pretty happy with. In my mind it was such overkill and he was being academically ostentatious or something.

I now love having opportunities to lean on finite state machines because I’m more aware of how dumb my primate brain is and how helpful it is to have guard rails. So, multiple layers of dumb: I couldn’t figure out that this guy was smart enough to see how dumb we were in the context of the problem we were solving, and he was ultimately trying to save me from myself.

This was around ten years ago.

I’ve also been told I’m a great teacher, haha. Sealed.

[majormajor]

This is a fun example because I've seen exactly the reverse situation. (Not to say state machines are bad, just to say sometimes they don't fit as much as it seems on first glance.)

A bunch of mid-level devs on the team wanted to model our new thing as a state machine. But it dealt with a LOT of edge cases. Including real fun things like "that actually CAN be a valid state transition if Customer Service does it to manually resolve an issue caused by a previous bug or something, or just to make a customer happy, even."

I was the guy who eventually convinced them not to by illustrating just how many states and transitions this machine would actually have to have to do everything it needed to. A lot fewer people want to write thousand-node state machine descriptions than who want to write 20-node ones.

(How did I know that would happen? Because I'd previously been a mid-level engineer who jumped straight to "state machine!" for something and it added countless complexity and pain to the project. :D )

[steve_adams_86]

Absolutely, that's a legitimate concern. A real benefit of approaching state machines model-first is that you get to see those nodes on paper before trying to write the code, and you can quickly recognize a tire-fire of an idea vs a situation where you can sanely box in logic and avoid state-explosions.

I've had a few tasks with state machines turn into messes, but thankfully they were only at the cost of my personal time rather than my team's. I definitely prefer them for cases where a model juuust fits into your head, or nearly so — it seems fairly intuitive, and not totally monolithic in scale or inversely tiny in proportion. There's this sweet spot where it's just complex enough that you want to box it in, but not so complex that a formal description using a rigid convention would endanger you from your coworkers.

[majormajor]

Yeah the attempting-to-model first approach is great too for trying to avoid walking into "we thought this would take three weeks but it's gonna take 6 month" situations because the initial requirements were not all the way thought through around edge cases and such, and looping stakeholders in to just how nasty it may or may not be early-on.

[steve_adams_86]

That dovetails really well into our other thread about putting an emphasis on listening and understanding rather than trying to lead conversations. Putting attention to properly understanding a problem is very empowering, and often leads to more decisive data points than discussions can.

[Too]

Ooof, saw a team get hung up on modeling the application as a state machine once. No existing solution could support all the edge cases so they had to write a templated state machine engine first.. Yeah.. No surprise what happened to that later.

[steve_adams_86]

I think going state machines all the way down is almost always a mistake. I can maybe see using state machines to undergird some logic in an application, like… I don’t know, maybe you’ve got some authentication stuff you’d like to reliably model as states, and that’ll be fairly foundational. But if you then model authenticated and unauthenticated states as substates, then have further nested states representing the sort of scaffolding or actual features of the application… That’s a nightmare.

I’ve noticed some people are hesitant to compose state machines too, like using dumb states to execute smarter state machines such that you can localize complexity and isolate things better. Almost like people think it needs to be a monolithic machine in order to truly maintain safety?

In any case, like any pattern there’s plenty of room for abuse, haha. I am a pattern abuser myself, usually learning things the hard way.