Why Developers Never Use State Machines

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 :).

Image by tfangel

  • The Trav

    Completely agreed on state machines.
    I’ve used them a handfull of times on various projects, and seem to be coming away with better results each time.

    I don’t know much/anything about the ruby state_machine gem, but I’d imagine it’s relatively light weight, if not it shouldn’t be too hard to roll your own, all you really need is a transition function.

    If you’ll forgive the shameless plug, here’s a solution we recently came up with for grails that evolves the one linked in uses a little:

    Biggest benefit I found with having the state machine was actually in the soft skills area. They make it quite easy to draw up straight forward diagrams which tend to be all inclusive without getting stupidly complicated, that makes a great tool for sharing understanding with both technical and business oriented clients.

    • DSS

      State machines rock. I’ve got a hardware (EE) background, and in digital logic, state machines are as common as the ballpoint pen. So using them in software, for me, is almost the de-facto choice, unless another option seems to be clearly better.

      I do most of my development in C & C++ (as an embedded guy, imagine that?) There are many choices to use — in C++, there are free alternatives (besides roll your own) such as Boost’s 2 offerings, or any number of object-oriented implementations of the State Design Pattern.

      Another interesting choice is the Quantum Platform (http://www.state-machine.com/qp/), which is an event-driven state machine framework in C and C++. It supports both flat finite state machines (FSMs) and hierarchical state machines (HSMs), including most features found in UML statecharts such as entry & exit actions, initial transitions, superstates & substates, history, etc. Many of the embedded systems I’ve worked on use the QP (open source, but must be licensed for use in a commercial product). Having a framework manage things like event passing, event pools, tracing & logging, etc. really simplifies things, increases quality & reduces development time. (Most of you in the non-embedded world often have a variety of frameworks to choose from… in our world, frameworks, or at least good ones, are pretty rare.)

      One of the nice things about the QP, and software state machines in general, is the traceability from design (state transition diagrams & UML statecharts) to code/implementation.

      • mspspeak

        Agreed 100%. In digital design, the tried and true optimized approach to designing a digital system is a state machine. We’re talking hard core nerds way smarter than we’ll ever be came up with this stuff. It’s golden. Your garage door, all your appliances, the elevator, your kid’s toys, assembly line robots, etc: all most likely state machines under the hood. When you want to implement a system with the minimal amount of logic circuitry, state machines do it for you every time. (especially implemented with a tiny bit of eeprom memory)

        It’s a shame more software devs aren’t exposed to the hardware side of thinking about low level systems design.

        Erlang and it’s pattern machine is evidently the SUPER BAD ASS for state machines but I’ve yet to play.

        • mspspeak

          replace “pattern machine” with “pattern matching”.


  • P

    You don’t even need to be doing OO. Reading a file when you want to match a pattern in a certain section you have the 3 states “start”, “in section foo”, “after section foo”.

  • Pingback: Dew Drop – September 1, 2011 | Alvin Ashcraft's Morning Dew()

  • Frank

    I’m actually surprised by the number of devs I’ve worked with who didn’t know what a state machine was; then some who knew, but didn’t see the screamingly obviously patterns asking to be managed by a state machine.

    Totally agree that state machines should be given a bit more attention by developers in their day to day working.

    • I have a very basic idea of what a state machine is remembered from long ago CS courses. But not enough for there to be ANY blindingly obvious problems (or ‘patterns’) that to me suggest a state machine solution. (Well, perhaps other than a regular expression parser, since I remember implementing one with a state machine. A DFA or NFA is a state machine… I think…. right? I may not know jack here.)

      Even after reading this blog post, it’s still not clear to me! If one of you wanted to write a blog post with some examples of problems obviously well suited to a state machine solution, it would be helpful!

  • Ryan

    I think the observation, “developers don’t use state machines,” may be domain specific? All products I’ve worked on have state machine implementations at the core of many different sub-systems.

    • Yeah it is perhaps more applicable to web developers (that’s the area I know), from all the comments around this post, I am getting the impression that in some areas, state machines seem to be almost ubiquitous. Although I would say that the people in those areas would be in the minority rather than the majority.

    • Aggelos

      Sad but true.. you can see so many blog titles today claiming that “Developers don’t do/know/use [put any computer-science 101 term here]”. If this is really true and not a way to gain traffic then there are very few (real) developers around…

  • Great post. It is an interesting question why developers don’t use state machines more. This was also the reason for me to write my blog post: the Shopify code base contains some code that would have been a lot better if it would have used an explicit state machine. We are now correcting these mistakes, but the audit trail of state changes is gone for good in these cases.

    Keep spreading the word!

    • Hi Willem,

      Thanks for the audit trail gem by the way (writing it and letting us know about it), it’s been working great for us. I am still kicking myself that we didn’t start using state machines sooner, won’t be making that mistake again.

  • Very early in my career I worked with an extremely-experienced programmer that loved state machines (when appropriate). I’ve used them many times in code, and always to great effect. When design patterns came out I really liked the book because I was already using various patterns (like the state machines) I had learned informally from more experienced programmers. Unfortunately, it seemed to go off the rails as everybody took it literally, and used them as building blocks, rather than just patterns to build on. It seems to be the case that programmers gravitate towards the popular ideas (which get diluted), while choosing not to learn from the others around them. State machines are an excellent example because it wasn’t uncommon at all to see them in systems programming for problems like protocol handling, but now it seems like they’ve been forgotten. We’re an industry prone to not learning from our own history or experience …


  • Alex

    I think you just barely missed why most developers don’t use state machines. Most languages/environments *don’t* have a half-decent state machine library. Ruby’s state_machine is actually one of the only ones I’ve seen, perhaps because Ruby offers some amount of syntactic abstraction. But how would you write a state machine library for C or C++ or Java? I can’t think of a way to do it that wouldn’t be terrible to use.

    State machines are great, but they’re sufficiently different from typical procedural programming languages that we’re just now on the cusp of mainstream languages being good enough to really implement them well.

    • Will W

      There are loads of good state machine tools for C and C++.
      They tend to be based around some form of code generation. The one we use is a spreadsheet you put all your states and events in, and a little tool that produces some C that implements that, using a template. Dead easy to work with.

      2 comments on the original post:
      Unsurprisingly a large proportion of the general discussion on the web is about web technologies. But don’t forget that there is still a massive industry in systems and embedded code (where I live). I spend my time mostly writing comms stack layers in C, and trust me, there are state machines EVERYwhere.
      As such, in that space there are hundreds of tools and systems that you can use for working with state machines. I think the web-dev world probably doesn’t lend itself to state machines quite so easily and obviously (although they would still be tremendously useful) so the ecosystem hasn’t built up around them.

      “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”
      This is a standard software problem, in all domains. One of the hallmarks of good software (and good coders) is that when the software has evolved you have another look at how you’ve done it and refactor it appropriately.

      • Alex

        “There are loads of good state machine tools for C and C++.”

        Funny, I’ve never seen a single one.

        “They tend to be based around some form of code generation.”

        Oh, that’s probably why. People still think this is a feasible method? How do you refactor? Do you write your own editor mode, or is it in something like XML? How do you step into it with your debugger? Code generation from a completely different language is such a bad idea I’ve only ever seen it with old systems that need to generate C — HLLs avoid it like the plague.

        “The one we use is a spreadsheet you put all your states and events in, and a little tool that produces some C that implements that, using a template. Dead easy to work with.”

        Ouch. Let me file that right after “There are loads of good object systems for C … we use one called CFront”.

    • Ernesto Gomez

      in any language that has 2D arrays, implementing a state machine is trivial – all it takes is (i C-ish syntax): First, number states and events

      then define array :
      M[event][state] – the contents of the array is the state you want given your current state and the event you have just seen. The machine is:


      you can always follow this with
      switch( state ){
      … etc.}
      if you need to link actions to specific states. I’ve used this many times as a developer and I teach my students to do it as well.

  • I haven’t used them widely, but for GUIs with lots of interacting moving parts, state machines are the way to go. A few years back I wrote a state machine on top of wxPython that made it infinitely easier to build complex GUI logic, reason about it, and debug it. And to my surprise, I ended up using the same state machine class to handle some protocol logic a few weeks later.

    An interesting detail: I don’t know if it is a widely used idea to couple exception mechanisms with FSMs, but my experience was that using Python exceptions in order to back out of failed transitions was a cheap and easy way of robustifying my code.

  • I was one of about a dozen instructors who taught tens of thousands of developers at Motorola the Hatley-Pirbhai design method, which used state machines for the control model. I later provided an entire chapter on developing state machine models and testing with them in my book, “Testing Object-Oriented Systems”.

    I’m glad to see that this wheel is at least being re-discovered. The programming case is simple: you can define a state machine controller in no more than 20 lines of code, which can be reused easily. This uses a table (inline, a text file, XML, etc.) that represents the machine. The alternative is idiosyncratic re-coding of nested if or switches running to hundreds or thousands of LOC, for every applicable control function.

    As far the CS theory goes, I don’t think you need to know it to make effective use. The basic logic of state machines is simple and elegant, and if explained clearly (no mumbo-jumbo or greeks), is easy to use and apply. There are few abstractions in programming that have as much conceptual leverage over complexity and universal application.

    However, if you don’t get the key concepts right (what is a state, a transition, an event, and action), you’ll end up with muddle that isn’t much better than a 1500 line switch. Having taught this to many testers and devs, I can assure you that it is difficult for some people to get clarity on the key concepts. The Moore formulation should be avoided, as it usually contributes to confusion. Under no circumstance should one mix Mealy and Moore.

    The biggest source of bugs in state machine implementations are “ignored” events: in state X, the response to event is unspecified. Unless you make explicit what “ignoring” means, bugs will almost surely follow. The table should have explicit entries for every event/state combination, even for those that are “ignored.”

    • Robert Jones

      Holy flashback, Batman! “This uses a table (inline, a text file, XML, etc.)” You just made me realize that a program I wrote years ago may have been a state machine. I certainly was not thinking “state transition” explicitly. Maybe it is the “chain of command” pattern? The XML config listed a couple of different code execution sequences and a factory instantiated a “made to order” list of objects. A state table seems more “elemental” than that; a more fundamental fabric of space-code-time as it were.

  • In video game programming I used state machines every day for decades. I even wrote three compilers making more and more advanced state machine based languages (an article on one of them: http://all-things-andy-gavin.com/2011/03/12/making-crash-bandicoot-gool-part-9/ ). Every game object was a state machine of sorts. I also used them extensively for managing file/data loading, memory management, and even handling the Playstation Joysticks!

  • michael

    Just a point of terminology clarification: The term “state machine” means a machine that has state. For instance, a typical class in an OO language is a state machine: it has state as member variables, and is a machine because you can act on and interrogate it. All coding involves the use of state machines. The term “finite state machine” is the specific thing you are discussing here.

    Web developers often use FSMs without realizing it. Every time you create a regular expression, you are creating a FSM in the underlying library code (IIRC the standard algorithm involves generating a NFSM for the parse states of an incoming token stream, and then computing an equivalent DFSM).

    I think one reason I don’t often explicitly write FSMs is that the resulting code doesn’t generally make it easy to deduce the FSM model back out from the code, making it hard to maintain. For instance, I worked on a project where someone had written a complex pair of FSMs with about 12 states each and dozens of transitions to track the state of a certain type of object. Over time, hacks to add new functionality had changed what was probably once a pretty clean FSM design into a buggy mess. Nobody had taken the time in years to generate and analyze a diagram of the FSM based on the code until I was given the task of fixing it. It took quite a while to draw out all the states and transitions, particularly because the hacks had added side effects and such that broke the FSM abstraction. Once I had done so, it became clear that the desired behavior of these objects would be much better modeled without an FSM.

    FSMs are great for a number of things, including protocol decoding, game AI, language parsing, and lots of others. But they can be difficult to maintain unless you have specific tools or libraries that make the underlying FSM visible.

  • David Phillip Oster

    You already have a state machine library for C or C++.

    One of the things you learn when you are getting a Computer Science degree is that a state machine, or as we call them, Deterministic Finite-State Automata, and a regular expression are equivalent to each other, and that it is possible to convert a collection of state machines into a single state machine (a non-DFA) that examines each input symbol at most once.

    If you have a Unix computer, like a Macintosh, it comes with a code generating tool called flex (that’s the gnu version, it does the same job as lex) that takes a list of regular expressions and C or C++ code fragments, and creates the source code for a function, that when compiled and executed, and handed an input, executes the code fragments as they are recognized.

    So, don’t roll your state machines by hand, use flex.
    Note: one of the original authors of flex is Eric Schmidt, chairman of the board of Google.

    • David Phillip Oster

      Correction: One of the original authors of lex is Eric Schmidt, chairman of the board of Google.

  • Shayne

    I haven’t looked at the Ruby state machine implementation, but I did build my own as an exercise in C#. In a static typed language, it IS harder to build something that is pleasant to use. Here is a brief introduction that I started on, link to the code at the bottom.


  • As a self taught developer, state machines were a totally unknown concept to me as of today. But the problems enumerated in the ‘great post’ have puzzled me many times. Looks like there’s a proper way of solving them. Interesting.

    By all means, everyone, do read the linked post, it is an awesome piece of information indeed.

    Alex, could you explain for us noobs why C, C++ or java would not be up to the task? not being sarcastic, just genuinely curious.

  • It bugs me when web developers try to pass off their “wisdom” to the greater developer community. The typical web site is a spaghetti ensemble of ${scripting_language} without much design beyond some basic OOP.

    Good state machines can easily be built with “switch” type statements and even standard conditional type statements (if/else if). You don’t need a library.

    State machines are used all over the place. Your TCP/IP stack, web server, scripting language, JS engine, etc all use them and developers of these things readily rely on them. Web developers do not because the barrier to entry and acceptance is so much lower.

    • Gerardo Orozco

      I agree 100%. I really don’t see the need for overcomplicating things using a library. I code my state machines using a simple function pointer (or delegate) holding the current state. Each state being a function, it becomes easy to transition to a different state simply by redirecting the pointer to a different function. Your state machine then simply becomes a while loop executing whatever “state” is being held by the function pointer.

    • Artemiy

      “You don’t need a library.”

      Well, if *you* don’t need a library, more power to you, give yourself a pat on the back for that. However, libraries do sometimes provide useful features and integrations that reduce the LOCs and improve the readability.

      • DrHouse5

        No one needs a library to create a FSM!
        The whole point is that switch is a superior solution to the gobbledygook in the article.

        • Artemiy

          Just because you *can* create an FSM with a “switch” statement, doesn’t mean it’s a superior solution.

  • Must be different for different groups of people. I can’t remember a serious project I have worked on in the last 15 years that did not have one or more state machines that we built. It is a beautiful construct when it is applicable, which is pretty frequently. On the other hand, what surprises me is the lack of use of stacks. Somehow I always thought I would use stacks more often that I did…

  • James Bailey

    I’ve used a framework based state machine once. I wrote an email client for the Apple Newton in the middle 90’s. It struck me at the time that both POP and SMTP were both state machines. The Newton developer tools had a very nice object oriented state machine framework. It worked pretty well but after months of development, it started to get a bit unwieldy. When I needed to add attachment capability, I had to rewrite more code than I would have with a more usual design.

    I also worked for a company designing CNC machine tools. One of their big software projects was based around a massive state machine. Given how poorly it was written, I probably should have never even considered using a state machine again. The states had multiple entry and exits. It was just a mass of spaghetti and the state transitions were just elaborate gotos. Really awful to work on.

  • One concern with state machines is they are not very modular. Extension of a state machine means introducing new states, new transition rules and guards. One must reach ‘deep’ into the state machine to effect such changes. Even if we extend a state-machine with user-defined triggers, the developer must have a deep understanding of what is happening ‘inside’ the state machine to define these triggers appropriately, thus this is not compositional.

    If we do not need to configure, compose, or extend a state machine, then it can serve as a simple (and therefore valuable) device for managing and understanding state. There are many cases that fall under this umbrella. But I think they are too low level and rigid for many direct applications.

    • Mark Uebel

      You should look at the North State Framework for implementing state machines. It allows for composition, inheritance, and extension. A well designed framework can even allow state machines to be used as base classes, providing an interface for other classes to hook into, based on a generalized state machine design.

  • Warren Young

    You write state machines in C++ like [this](http://www.boost.org/doc/libs/release/libs/msm/) or like [this](http://boost.org/doc/libs/release/libs/statechart/).

    The key, I think, is having it built into the language or the standard library, which it isn’t in the C++ case nor in most other languages’ cases. Third party components — no matter how carefully designed, and no matter how carefully curated their repositories — will always be at a big disadvantage compared to built-in features.

    To the list of languages that does supply an FSM implementation with the standard library, I’ll add Erlang’s [gen_fsm](http://www.erlang.org/doc/man/gen_fsm.html).

    • DrHouse5

      It’s called SWITCH in C/C++/Java/C#/et. al.
      Maybe you know them as SELECT CASE.

  • Matt Nolker

    I recently used a state machine on a mortgage origination and processing project. Mortgage applications pass through many different thresholds of trust and accuracy Quite a few things we wished to tell users of our system would change based on the state of their mortgage application. It turned out to be an excellent technical design for a non-existent problem. Users found little value in the things that depended on the state machine. And as we began to understand the domain better, we found ways to accomplish most of the useful tasks without tracking the mortgage application state. But by then it was too late. There were calls to the state machine throughout our application. Ripping it out would be very time consuming. Maintaining it was also pain. The effort it took to write tests that accounted for all the possible states was a significant time sink. In the future, I’ll look harder for opportunities to simplify the problem first.

  • Mark

    Nice example of a state machine to solve a real problem, and how it was chosen over an alternative:

  • I use state machines daily.

    For text parsing, GUI management, hardware device control and also geometric algorithms design (e.g polygon intersection).

    Very handy for pen and pencil design, then well controlled coding.

    Always my own coding with nested switches or clean goto’s. Sometimes with as little a two states!

  • Ph A

    I’ ve seen state machines used a lot, and I frequently do so myself. Actually, as from the point of using the second elseif (in an if .. then .. elseif statement), one needs to consider using a switch statement (to mention C). And exactly thát is the start of the most basic state machine ! To me, this looks like good coding practice. Of course, you need some good design… FIRST (which is where it mostly has gone wrong already before, due to some “qualified” boss who has told you to “deliver me something that does something … presto”).

    On the other hand… if some programming language needs a library to enforce using state machines, or to code them : get rid of it! So get rid of .Net, e.g., a sheer hobbyist language. Yes, I know : “Everyone eats shit, so why wouldn’t I do so too ?”, isn’t it… Ever heard of Ada ? Yes, widely unknown, but in that programming language, state machines are so to say a “second nature”.

  • Andrew Fry

    I worked on network protocol stacks for many years and used state machines on most of them.
    Indeed, many network protocol spcifications are described in terms of state machines.

  • A quick testimonial: State machines rock! Just this week, I needed to write a command line tool to split out subsections from large documents. Once the Python grew to a particular size (but not really that big), it got buggy and I couldn’t easily see why. I grabbed a sheet of paper, drew my state diagram, rearranged my code, and it worked on the first run.

  • blackcat

    I would like to add, that state machines (at least an abstract notation, if not a true implementation with status variable), are very useful in unraveling some intricate situations regarding complex algorithms that are normally treated with flow charts. In my experience, I’ve found that the representation of a algorithm in a state machine form, produce a much more compact (and manageable) graphical form respect to flow chart. Between flow char form and the state machine form, the semantics remains the same, but the compactness (and, hence, readability) can be almost an order of magnitude better. After all, loops (not necessarily loops with indexes) in conventional algorithms, can be considered as real states. So, as an ex hardware designer, I’ve brought some concept from digital design and mixed it with the semantic actions (that are tipical in some notation used in software) involved in the processing. Next, I’ve added some “decorations” to arcs (priority, predicate and semantic action). Once I have the graphical state-machine algorithm’s representation, it’s pretty automatic to convert it in real code (with or without status variable), i.e. to convert it in a flow chart or directly in – e.g. – C/C++ (or any other language) code. The primary benefit to use SM representation for an algorithm, is to have the complete control, state by state, of the completeness of the checking of the “decision predicates” (functions that determines the “traveling” from a state to another and the “firing” of the associated semantic actions), resulting in more robust algorithms.
    Sorry for my english…

  • In the last 4 years I have “always” preferred to add a “status” attribute quite eagerly to all my entities when programming anything serious. Your post only gave me more confidence to take on some YAGNI diehards…thanks :)

  • Scott

    Nice illustration of “Premature optimization is the work of the devil”.

    You could have saved a lot of verbiage by simply stating: “Because they’re not necessary in most use cases and 99% of the people who are going to have to maintain that code will have absolutely no idea what to do with one.”. If you’re trying to write code that will be useful in 5 years instead of trying to show off how incredibly smart you are, the latter is an important consideration.

    At any rate, thanks for the engaging blog post- it’s given me some ideas for essays of my own, such as: “Why shoppers never use V22 Ospreys for grocery shopping” and “Why sysadmins never use a Connection Machine running Ingres 7 for managing user logins”.

    • Al Bunch

      I may not need a V22 Osprey to get my grocery shopping done, but I do occasionally need an A-10 to get trough the checkout line. Peace through superior firepower.

  • Our Umple technology (http://umple.org) adds state machines directly into Java and PHP (With C++ coming). It also adds other UML abstractions. With Umple you can create state machines that are nested as deeply as you like, with actions on entry, exit, and transitions. You can also have UML concurrent regions.

    I completely concur that developers don’t use state machines much. One reason is that they are not in the base language, which is why we put them directly into Umple at the code level.

  • Pingback: We Don’t Need One Until We Do « MulderX()

  • Pi

    Have you heard of IEC61499? Its an industrial automation framework thats supposed to incorporate state machine use

  • cremes

    For Ruby, I have found the statemachine gem to fit my brain better than the state_machine gem (yes, they’re different).

    Check it out:


  • Pingback: Всем сотрудникам отдела! «()

  • Shameless plug for a lightweight statechart implementation.

  • Anders

    It ‘always’ a good exercise to draw your domain-entitys state machines on a white board. Many good discussion has started from it and helped us to reason about the complexity within the system. Often when someone is trying to explain domain problem to I tend to end up drawing those machines. I also like the Refactoring to Patterns view about when to explicitly creating the in code.

  • Pingback: Becoming a Great Programmer()

  • Pingback: SIDA: Moving Object-Oriented Design beyond Model-View-Controller « iHack, therefore iBlog()

  • Pingback: Friday Link Party – what we’ve been reading | Grinding Gears()

  • Pingback: The key to good Code()

  • About 20 years ago my manager needed two small almost identical projects to be completed quickly. It would have been better for the purpose of not duplicating code to have done them sequentially, but for expedience they were done in parallel, and independently, by myself and another programmer (Jim).

    Jim was a very clever guy, certainly more clever than me, and I worried about him doing a faster and better job. I put a lot of effort into quickly creating a simple solution and had the task completed in two hours.

    On the other hand, Tim was very keen on state-machines and thought the project was an ideal, if simple, candidate. He evetually got his project working (with bugs) in two days. Luckilly, the code never had to be modified as most people would not have been able to understand how his solution worked without quite a bit of study.

    This demonstrated to me that state-machines are not particularly useful for a simple, maintainable solution. Perhaps for much larger projects, such as creating a compiler, using a state-machine would make things simpler but even there in my experience a recursive-descent compiler can be almost as efficient and certainly eaiser to understand.

    • Ryan

      dafuq is a “recursive-descent compiler”? You mean “parser”? This post is all over the place.

      • DrHouse5

        If you work in even fucking IT should be aware of parsing tech never mind if you code for a god-damned living.

        Your redneck is showing; please hide it.

        • dan

          The farther I scroll down, the more useless your comments become. I think your brain is in a recursive-descent pattern. ;)

          • nickman

            Absolutely top notch reply to him mate.

  • Your reasoning for why you weren’t using state machines is pretty spot on. And I think this is true of many of the other more intermediate and advanced techniques in programming as well. Our experience leads us down paths where we often aren’t provided the resources (time, energy, financial support, people) to explore solutions that are correct. While this is generally not ideal, so many programmers settle with employers that don’t provide them room to really grow, and have evil constraints that prevent them from exploring more advanced practices.

    I can tell you I’ve avoided state machines for precisely the reason you mentioned. Initially I don’t think I need a state machine, and later on, after tens of migrations later, I realize that a state machine would have been absolutely ideal. The idea that I need to spend a considerable amount of time to migrate to the state machine (and work with a new gem that has to be learned as well) is not a desirable one.

    That said, I think state machines are fantastic. Any time I have an attribute like status I will always use a state machine from here on.

  • Warren Young

    @Andrew: If the problem is simple, a formal state machine probably isn’t the right thing unless you are using a facility built into the language, so that anyone claiming to know the language should be able to look at the code and immediately see what’s going on. (Or at least, you would expect them to get up to speed quickly, via the relevant docs.)

    The thing about complex problems where the solution system really does move from one state to the next is that, if you are not using a formal state machine mechanism, you will have invented an informal one anyway. As the number of states and transitions grows, the more spaghetti-like your code will become. This is because, in an ad hoc state machine, state variables tend to get scattered through the system, and transitions happen in whatever way is expedient at the time.

    I propose that the best way to decide when to move from ad hoc to formal is when it becomes easier to figure out what the code does by looking at a state-transition diagram than the actual code. The problem with diagrams as documentation is that they tend to get out of synch with the program’s current actual behavior. By moving to a well-tested reusable state machine library with a nice API, you are moving the documentation for the program’s behavior back into code space.

    If the clearest diagram for the program’s behavior looks like some other type of diagram, don’t shoehorn it into a state machine.

    If you can’t find a third-party library that does what you need, don’t write one yourself. The purpose here is to fob off some of your app’s complexity onto some third party you trust to do at least as good a job as you would. You are also expecting to get the benefit of a well-designed and well-tested library interface, something that is best achieved when many different people are banging on it from different directions. If you’re just going to reinvent the wheel, there seems little point to the rewrite. You’re likely just going to end up with two piles of spaghetti instead of one big one.

    • Ryan

      That’s bullshit. Languages don’t need built in “state machine functionality”. That’s just hipster, use-a-library-for-everything mentality.

      • the Gods

        Ryan sucks!

      • You don’t need a library or a built-in syntax, but if you have macros you can emulate such a convenience.

    • BlueBoomPony

      Any language with if-then and loops can do a state machine. It helps to have switch (C and variants) or case (VHDL), but it’s not necessary.

      I find that people who come from hardware backgrounds like me tend to like state machines more.

    • Manuel

      Somebody has to write those third-party libraries

  • Warwick Molloy

    State machines are very useful. I’ve used them scores of times in the past, particularly for processing XML, HTML, log files, as simple parsers and lexers. They’re also very good for protocols.

    I would recommend avoiding libraries and tools for generating state machines. Why? Because you often end up with a bigger, more complex mess that’s harder to understand.

    A FSM can be implemented very easily with a state transition table (two dimensional array) and an actions table (again, an array) and one integer to record the current state. The arrays are constants, so there’s one copy for all instances but the integer storing the current state is one per instance so this scales incredibly well when dealing with thousands of TCP connections or the like.

    The trick to the arrays is to have the row be the state and the columns representing the event to handle. The size and meaning of the transitions and the actions are basically the same, the value in each cell is the next-state for the transition table, and a code representing what action to perform for the actions table.

    Finally, you need a method that takes an event as a parameter, uses that event index and the current state to lookup the next state and the action to perform; have a switch/case to decode the action and perform it; and then update current state (current_state = next state).

    This code is very easily debugged. The FSM can be drawn on paper from the source code by starting in state zero and noting transitions and actions triggered by each event.

    This can often be done in about a page or two of code. The trick is your machines get better over time and you can achieve more with less states.


    • Seyfettin E. Devrim

      Man im glad that you described how you implement state machines. Im a newbie to java and just finished my first “little” project and i was very curious how a state machine implementation (simulation i should say) would look and work like? As far as i can say in my humble opinion as a newbie, the 2dimensional array approach is hard to mess up and is simply elegant

      • DrHouse5

        He described an absolutely terrible method to implement them.
        Never, ever do it that way.
        Just code them with a switch statement.

        KISS. Don’t use table-driven data-bullshit instead of using a built-in language construct.

        • sle7en

          Dude why are you responding to something typed 2 years ago? WTF?

          • Pradip Vaghasiya

            so that I can read it!

          • Everlast

            And me too, and I agree it is not a very clean way to do it.

          • Klassy

            Forums are forever man. Doesn’t matter if the OP ever sees it… WE see it.

          • Meri

            Exactly this, it’s been even more time since the original post and im here o read it :)

          • Chris Johnson

            Everyone understands necroposting Sle7en. Point being is I read this for the first time today, a year ago from your comment which added nothing to the thread, and I am curious about the commentary of a differing opinion. Keep perspective man.

            In the spirit of contributing to the discussion without inane comments, DrHouse5 that makes some bold assertions without an ample display of why the position asserted is better: I was curious to learn why table driven, data driven, component based architecture is bad? After years of OOP it seems we have come full circle to the the assertion DrHouse5 makes is…empty.

          • James Cat

            agreed, both methods seem valid, I’ve implemented a state machine as nested switch statements and it’s a mess, table sounds cleaner in this respect, but I can imagine it would work well for other state machines, I keeps an open mind.

          • bmarkovic

            Massive switch statements are exactly the antipattern that table-driven FSMs solve.

          • Why So Serious?

            So young. So short-sighted. WTFF? Hey, dudes, can we please stop with the necrothreader hate? As someone older than the Interwebz, I really, really, really, really, really, really find it tiresome. And that’s saying something. Get perspective. You can either continue with the herd mentality or you can get over your inability to see something as relevant if it is more removed from you than the time dilation of youth allows you to easily grok. You are the reason that older people don’t interact in communities where the truly immature are the mainstream threaders. Funny to watch so many thirty-somethings finally maturing to the point of being aware of how stupid and needlessly limiting this attitude is. If the writing remains relevant to my life today, the age of the thread is not of consequence. You can breathe through your nostrils, too. You’re welcome.

        • Could you explain why his method is terrible and your method is good?

        • feloneouscat

          Sorry, but table driven state machines are the DE FACTO standard. They exist because they work well and are easy to document (and read).

          As for “code them with a switch statement”, AFAIK, most state machines I have seen that are table driven USE A SWITCH.

          So, either you don’t know what you are talking about, don’t know what a FSM is, or really, really, need to explain what you are talking about, because it is unclear.

        • KarjamP

          Warwick’s approach seems to be unnecessary complex. After all, you don’t need to mimic actual state machine tables within code now, do you? His approach does not seem optimal. While Warwick’s approach does seem to mimic how one would model state machines within a transition table, this is unneeded when it comes to representing your code. In fact, this might actually result in performance drops since it may be unoptimal within the code.

          KISS stands for “Keep It Simple, Stupid”. It refers to the tendency of developers resorting to complexifying their code when doing so would be completely unnecessary. Examples of where this would apply would be when a developer uses Object-Oriented programming when simple statements would do fine and, of course, Warwick’s approach.

          Complexifying your code when it’s not necessary to do so misses the point of programming. You’re supposed to be solving a problem through code. Nothing more, nothing less. Your code must also be manageable. Otherwise, you’d struggle maintaining it when the time comes for you to do so.

        • Leonardo Piccioni de Almeida

          If it results in legible code (more likely in languages where associative arrays are primitive types), one should prefer to use branch tables. It’s much more efficient, especially if you compare n-dimensional branch tables with nested “switch” blocks.

          In fact, a very good compiler will try to convert large switch blocks to branch tables, if suitable (for example, if all cases end with “break” statements).

        • Carl Gifford

          I used data driven state machines nearly identical to Warwick Malloy’s description in industrial environments for over 30 years. They are easy to setup, maintain and modify. The array driven switch case easily enables random or sequential pseudo multitasking particularly in test environments where multiple samples (not necessarily identical ) are under life testing, or production testing. As Warwick pointed out Refinements and optimizations are evolutionary in progressive roll outs.
          I was able to get damn near realtime control out of round robin multichannel state machines. The dual array single index pointer approach works exceedingly well ! So have to disagree with you Drhouse5

        • Oladipupo Aina

          I agree on the KISS principle, it is a simple solution to simple problems.
          However, you will probably switch to an if construct once the number of possible States increases and also becomes more complex. I believe you should explore the use of State Design Pattern for such problems… just keep an opened mind

      • PaulMurrayCbr

        Remember that enumerations can have constructors, and that constructor argument can easily be a closure. This allows you to create an enum that has different behaviours for each state.

    • Sydney Lostarot

      man i have the feeling that you have a lot of experience in the subject … i would really appreciate a sample code to start (php or python if possible)

  • SB

    In my projects, there are at least two state machines banging away their respective states and keeping everything in lock step. Only a person who has developed a dozen different processes, monitors, and background operations would know how difficult this would be to code in an adhoc non-state machine fashion.

    • Ryan

      Also phrased as:

      “hey everyone, look at me, I’m such a smart senior engineer. Oh, did I mention I’m smart!?”

      • dan

        .. and yours could be phrased as:

        “hey everyone, look at me, I’m an ass who comments useless things in response to a perfectly reasonable argument for using state machines from an experienced developer.”

    • DrHouse5

      Only a person suffering from second-system-effect would ever consider changing out code for data (with zero net functionality gain) as a positive.

      • dan

        you sound like a manager.. have you ever actually typed a line of code?

      • Mike Terry

        Not a Rich Hickey fan, I take it.

  • Pingback: Finite State Machines in Game Development | Ext JS, Flex, and Flash Consultant – Jesse Warden()

  • Pingback: » Finite State Machines in Game Development iOS Gaming()

  • mkamoski

    Never use them? What? A state-machine is as simple as a non-nullable foreign key. It is an “abstract idea”, a design principle. Implementation is secondary. You have some nice thoughts and evangelization here in your article, but you are mistaken that “developers never use state machines”. Heck a boolean variable is a state machine– holds exactly one value from a finite set of values. Etc. Just saying. Thanks. — Mark Kamoski

    • James

      I think you missed the whole point of the article with your pedantic dissection of its title. Try READING the article and comprehending it before posting a comment.

      • mkamoski

        Did I miss or did the title of the article miss?

        • Lie Ryan

          Both. What you missed is what the article talks about is that developers need to use an *explicit* FSM as opposed to what developers usually end up with which is usually an *implicit* FSM.

          Having a single function that modifies the status field in various ways usually means you have an implicit state machine.

          When you have an explicit state machine, on top of having a status field, you also need a state machine runner, a state transition table, and you need to structure and design your transitions into the constraints of the state machine.

          What the article is saying is that developers should make their FSM explicit more often.

          • DrHouse5

            That is a second-system-effect design of an FSM and it’s a terrible design.

    • Mihai

      A boolean is not a state machine..it holds an information :)

      • mkamoski

        You, sir, are incorrect. See Wikipedia– A finite-state machine (FSM) or finite-state automaton (plural: automata), or simply a state machine, is a mathematical model of computation used to design both computer programs and sequential logiccircuits. It is conceived as an abstract machine that can be in one of a finite number of states. The machine is in only one state at a time; the state it is in at any given time is called the current state. It can change from one state to another when initiated by a triggering event or condition; this is called a transition. A particular FSM is defined by a list of its states, and the triggering condition for each transition.

        • frank

          The diefinition given in the wikipedia article is too general but does not entail the principles of its functioning. A boolean would be in logic terms only a sequential circuit at best, but definately not a state machine. A finite state machine has M inputs, N outputs, and k bits of state. Furthermore the k-bit feedback bus is not accesseble from the outside.

      • DrHouse5

        A boolean plus an if statement is a two-state machine.

  • Pingback: State Machine discord as system error detection | T. C. Mits()

  • Pingback: Rétrospective 2012 | Agilité, Architecture, C++ "in the mix"Agilité, Architecture, C++ "in the mix"()

  • Clearner

    HI! I’m a learner from China! I’m interested in State Machine.But I don’t know how to learn it.Please give me some references book.
    Thank you!
    My English is poor! Haha

  • Joe Marrero

    If you have ever written a large switch statement or have seen code with large switch statements, then chances are the developer could have used a state machine but failed to realize it.

    • DrHouse5

      Or entirely did realize it and thinks people that turn switch statements into tables of pointers are idiots that should be fired?

      • Lannister

        Still better than big switch statements… (Saw so big switch statements that doesnt even fkin compile and it was not generated programatically. -.-)

  • Pingback: 有限状态机 | squarey's blog()

  • Phil Rogers

    Having worked on numerous real-time systems over the years, I’ve used state machines many times. I’m currently working on a desktop application, which having a GUI is obviously event driven, so the state machine is appropriate there, too.
    I think your article title is incorrect. It should be “Why I, as a developer, never use state machines”, because clearly, other developers do use them.
    I use the UML tool, Enterprise Architect to design my state machines.

  • Fabian Meier

    In embedded programming state machines are the heart of everything. This is where the smarts are. In technical programming they are very common.

    • DrHouse5

      Yes but … you could get fired for implementing it this way.
      You cannot superfluously introduce pointers when they aren’t needed to solve the problem.
      It’s unassailably a safety issue and probably a security issue as well.

  • jameswatts

    Most people starts asking simple programs and later start asking to add features to it, but to design a good solution is needed to know the possible bounds and time, an FSM is more used while designing not while coding or even testing.

    Cases when i do not use FSM:
    1. Too trivial solution (undersestaimated the problem).
    2. It’s not my design or my code (and can’t force others to develop like me, but sometimes i do find very good design and excellent code written from others).
    3. There is no time for design and the solution is needed for yesterday (and our manager sold the moon and the stars).

  • Greg

    I’ve implemented a FSM for the first time, and I’m struggling with a detail that perhaps this group can help with: it’s the choice of whether to be “purist” and put all code that is related to the state inside the object that defines my state, or to put the code in a third-party object that the state machine manipulates via a public interface.

    State Machines are great because the interface hides the details from the calling clients, but my second option above is becoming messy since various state information can be inferred from the client’s details, and also be manipulated directly from anywhere in the application, which seems to break the reason for using the FSM in the first place.

    The first choice, however, means that I tie a lot of the manipulation of my application directly to the state’s object, which can be risky or annoying if I need to share information between states. I find it can be costly when an architecture is too rigid if it needs to be refactored in the future.


    • DrHouse5

      Stop. You have been led astray.
      If the state-machine is really complex go create a diagram using Visio or Enterprise Architect or whatever.
      Then code it with a switch statement.

  • Pingback: Finite State Machines and the reluctant programmer | richarddanielstein()

  • Tadas

    Every time I work on some e-commerce code I dream of state machines. And nearly every time it’s too late to introduce it.

  • Pingback: State pattern recap | IT procedures, tests and checks()

  • BlueBoomPony

    In VHDL/Verilog, state machines do all the work for me.

    Things like Mealy vs. Moore and all the cruft that they pile onto the subject in academic settings are best forgotten once you start coding state machines professionally. I’ve coded thousands of them at this point, and I couldn’t even tell you if they were Mealy, Moore, Happy, Doc or Grumpy. It’s just not important.

    In the real world, no one will ever look at your pretty state machine diagram for more than a length of time inversely proportional to the number of states. Honestly, I’d like to find out who popularized the “put the bubbles anywhere and loop the arrows all over the place” style for these things. Good gravy, just do a nice rectilinear style like a flow chart. People don;t have time to trace all your stupid loops.

    Sadly, they still teach two process state machines in universities which is an archaic and error prone method. Some of us in the tech industry have tried to champion single process state machines, but academics hate change, I guess. A recently published VHDL book had *three* process state machines which nearly made me advocate book burning.

    You simply treat them (in HDL languages, at least) as little mini programs. They are all unique and dedicated to a particular purpose (say, handling an I2C serial bus). Not even sure how you’d make a reusable state machine library. That just seems clunky. They’re so easy to write.

  • DrHouse5

    What are you talking about?
    Almost every time you write “switch” you are coding a state-machine.
    They are *everywhere*.

  • Gustavo

    Wanted to tell you that I find your post very informative and useful.

  • dlm080

    In digital hardware design, the average designer comes to rely on text-book state-machines way too much. For example, they’ll create a state-machine to convert one protocol to another (a protocol converter or bridge), when often the protocols are so similar almost no logic is needed. Usually the state-machine solution introduces wasted time for no reason. Also, an experienced hardware designer knows not to use one big state-machine when two or three smaller independent sequential control logic flops are better and can run in parallel, while a novice digital designer might make a huge state-machine that no one wants to take over, and probably wastes clock-cycles in multiple places.

  • Mark

    If you are a video game programmer you will use state machines.

  • Jamie Benzy

    Being a predominately middleware developer it confounds me why developers, especially front end developers are so adamant against software design patterns when they are screaming to be used. You don’t need to implement a specific framework, just understand the pattern, create a prototype and then integrate that prototype into your existing code. I believe that most software developers over complicate everything they do when they try to project their frustrated artistic or creative endeavors onto their software development. They are subconsciously trying to paint their own personal masterpiece when all that is needed is an Ikea bookshelf or entertainment center. Learn patterns, use the patterns so others will understand what you are doing. Go code your own esoteric labyrinthine masterpiece on your own time and prove to your own juvenile egotist self that your code rules the world.

  • Byrd

    This is clearly the opinion of someone who’s never worked on small-memory embedded devices, like DVD players.

    • Hi, I work with microcontrollers with small memory and find FSMs pretty useful, so I’m interested in why you have the opinion you have, which I’m not 100% sure, but it conveys a message on the lines of “do not use FSMs in small memory embedded devices”. Is my understanding correct?

      • Byrd

        Are you kidding? Nearly all DVD players I’ve worked on have some representation of a FSM in their firmware. To be clear, certain kinds of developers use state machines ALL THE TIME.

        • Hi, no, not kidding. I was simply not sure about what you meant with your comment “This is clearly the opinion of someone who’s never worked on small-memory embedded devices”.
          I guess it’s clearer now. thank you!

  • Ben

    I just had a look at a ruby state machine library – the learning curve is by no means small, because I found the documentation a little lacking – with the utmost respect to the coders and maintainers who put in their time for the project……….point being is that RIGHT NOW do the benefits of learning the api outweigh the costs? hmmm perhaps i should just have a simple state column in a table + add call back logic to ensure the states are always valid vs spending 2-3 hours learning the state machine api………seems like the short cut’s gonna win everytime, which is the exact point you made.

  • KRK

    Nowadays, many frameworks are adopting reactive coding which ends up with a huge switch statement. Basically, this is a state machine. Say, Redux is very famous and it uses state machine (although not finite states).

  • zenthrop

    What if I gave you a tool that could extract a FSM from random code? Would that be useful? Please let me know.

  • Nik Dek

    Thanks so much for this article! I’m facing the exact same problem. I work in a team of developers and I’m responsible for the program’s logic. Unfortunately no one in my team fully understands the problem I’m facing and the decision on how things should work is only mine. Currently the program works but its like spaghetti and any addition to new features (which keep popping up) is a nightmare as fixing one thing another one brakes. Coming from the computer engineering field I was feeling that a state machine would fit in such an environment but I wasn’t completely sure if it would worth the effort. You just made this clear, again thanks for sharing your experience!

    • hey Nik, unrelated to FSMs, but…
      for “Unfortunately no one in my team fully understands the problem I’m facing and the decision on how things should work is only mine. ” may I recommend you spread in the team the knowledge you have so the team itself can take a decision? that way, everyone is responsible for things that happen in the team and the weight in your shoulders is less. Win-win situation! ;)
      good luck!

  • Metin Erman

    Anyone who has made games is very familiar with state machines. I would venture to say there might not be a game that exists in the last 10 years that doesn’t make use of them. his seems to be a very short sighted post based only on personal views of what the developer has done.

  • bumelant

    We do use state machines all the time! In fact every computer program is a state machine – think about Turing machine. And many times when designing code to handle protocols or say invoice status kind of fields we use state machines or state machine like patterns, but it’s just a sequence of “if” statements and not always explicitly noted. I think formal state machines are especially useful for modelling documentation or syntax processing.

  • PB

    i think for most common daunting web programming it might not be needed (ea databases web solutions), engineering industrial electronics do use it a lot, to me i find that an area where you’l find most interesting peaces of code besides game development. But even simple object states can become quickly state machines, might be more widely used then you think..

  • Siddharth Shah

    Shopify page is throwing 404 :/

  • Why So Serious?

    Interesting article, and I think very insightful. So why now is the state machine all anyone can talk about on Unity like it’s just been discovered? Has something changed since then? Or is it just that state machines are the current popular fluffy bunny?