[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.