Share this:

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 (, 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.

    • Jonathan Rochkind

      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.

    • Alan Skorkin

      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…

  • Willem van Bergen

    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!

    • Alan Skorkin

      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.

  • Paul W. Homer

    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.

  • Taliesin Beynon

    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.

  • Bob Binder

    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.

  • Andy Gavin

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

  • Pedro

    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.

  • Kevin Bowling

    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.

  • Naeem Bari

    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.

  • David Barbour

    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]( or like [this](

    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](

    • 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:

  • Yves Daoust

    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.

  • samwyse

    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…

  • Hari

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

  • Timothy C Lethbridge

    Our Umple technology ( 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: Всем сотрудникам отдела! «()

  • GDSchultz

    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()

  • Andrew Phillips

    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.

  • Kevin Elliott

    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!

      • Erik Haliewicz

        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.

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

        • irregularexpression

          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.

      • 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!?”

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

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