Alan is what they call passionate about technology and software development. In his time he's done consulting, worked for large corporates, done product development, been part of an R&D/labs team and even done the startup thing. He's work in small teams and large, using methodologies that were Agile and no-so-Agile. You can always read his latest thoughts on his blog - and he even puts in the occassional appearance on Twitter as @skorks. Alan is a DZone MVB and is not an employee of DZone and has posted 6 posts at DZone. You can read more from them at their website. View Full User Profile

Why Developers Never Use State Machines

  • submit to reddit

A few months ago I saw a great little blog post about state machines on the Shopify blog. The message was that state machines are great and developers should use them more – given my recent experiences with state machines at CrowdHired, I could certainly agree with that. But it got me thinking, how many times in my developer career have I actually used a state machine (either separate library or even hand-rolled abstraction)? The answer is zero times – which surprised the hell out of me since state machines really are very useful. So I decided to engage in a bit of introspection and figure out why we tend to manage our "state" and "status" fields in an ad-hoc fashion rather than doing what is clearly called for.

We Don't Need One Until We Do

The problem is that you almost never create an object fully formed with all the behaviour it is ever going to need, rather you build it up over time. The same is true for the "states" that a state machine candidate object can be in. So, early on you don't feel like your objects' state machine behaviour is complex enough to warrant a "full-blown" state machine (YAGNI and all that jazz), but later on – when it IS complex enough – you feel like you've invested too much time/effort to replace it with something that has equivalent functionality. It's a bit of a catch-22. It's overkill and by the time it's not, it's too late.

A State Machine Is A Fluffy Bunny (Not Particularly Threatening)


Those of us who went through computer science degrees remember state machines from our computing theory subjects and the memories are often not fond ones. There are complex diagrams and math notation, determinism and non-determinism, Moore and Mealy, as well as acronyms galore (DFA, NFA, GNFA etc.). We come to believe that state machines are more complex than they actually are and 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 (except the … errr … theory). You have states which are strings, and events which are methods that cause transitions from one state to another – that's pretty much it (at least for the state_machine gem in Ruby). The point is, even if you have two states, a state machine is not overkill, it might be easier that rolling an ad-hoc solution, as long as you have a good library to lean on.

Even A Good Tool Is Not A Good Tool

I would hazard a guess that there are decent state machine libraries for most languages that you can use (the aforementioned state_machine for Ruby is just one example). But even a fluffy bunny has a learning curve (I am stretching the metaphor well past breaking point here). That wouldn't be such an issue if you were solving a problem, but all you're likely doing is replacing an existing solution. Since we tend to turn to a state machine library after the fact (our ad-hoc solution is working right now). Just like with everything that has "potential future benefits" the immediate value is very hard to justify even to yourself (unless you've had experience with it before). The slight learning curve only tips the scale further towards the "we can live without it" side. It doesn't matter how good a tool is if you never give it a chance.

It is really difficult to appreciate (until you've gone through it) – how much better life can be if you do give a good state machine library a chance. When we finally "bit the bullet" at CrowdHired and rejigged some of our core objects to use the state_machine gem, the difference was immediately apparent.

  • Firstly the learning curve was minor, I did spend a few hours of going through the source and documentation, but after that I had a good idea what could and couldn't be done (I might do an in-depth look at the state_machine gem at some point). 
  • The integration itself was almost painless, but moving all the code around to be inline with the new state machine was a big pain. In hindsight had we done this when our objects only had a couple of states it would have been a breeze
  • 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. Before it was YAGNI cause it was a pain, now we find that we "ai gonna need" after all, cause it's so easy.
  • Our return values from state transitions are now 100% consistent (true/false). Before we were returning objects, arrays of objects, nil, true/false depending on who was writing it and when. 
  • We're now able to keep an audit trail of our state transitions simply by dropping in state_machine-audit_trail (see that Shopify post), before it was too hard to hook it in everywhere so we had nothing.
  • We removed a bunch of code and improved our codebase – always worthy goals as far as I am concerned.

My gut-feel is that most people who read that Shopify post agreed with it in spirit, but did nothing about it (that's kinda how it was with me). We seem to shy away from state machines due to misunderstanding of their complexity and/or an inability to quantify the benefits. But, there is less complexity than you would think and more benefits than you would expect as long you don't try to retrofit a state machine after the fact. So next time you have an object that even hints at having a "status" field, just chuck a state machine in there, you'll be glad you did. I guarantee it or your money back :).

Published at DZone with permission of Alan Skorkin, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Daniel Slazer replied on Tue, 2012/06/12 - 12:23pm

Try running only your JRuby code using something that simulates what it would see while running in Tomcat. The goal is to create the same error. You will need to run it for a while.

Also try reducing the perm space with the command line option. You do that to insure that the error occurs sooner. Naturally you need to do this carefully as you don't want to obscure the real error.

Alain Picard replied on Mon, 2012/11/12 - 3:23pm

 Is there an equivalent to the Ruby state_machine gem in Java ?

Basil Abbas replied on Thu, 2012/11/29 - 5:50am in response to: Alain Picard

Stateless4j seems a very good alternative.

Alain Picard replied on Thu, 2012/11/29 - 8:24am in response to: Basil Abbas

 Thanks Basil

Henry He replied on Mon, 2013/04/01 - 5:20am

squirrel-foundation may be another option for java user.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.