Why aren’t statecharts used more?
Since statecharts are so useful, and supposedly have all of these benefits, then why aren’t all developers using these techniques?
Constructing the User Interface with Statecharts
Ian Horrocks has a section devoted to this, saying that
[…] if statecharts are as powerful as I say they are, why are they not widely used? […] Statecharts are not widely used for user interfaces because it is not obvious that such interfaces can be designed in this way. […] There is a general perception that user interface construction is easy because of the powerful development tools that are available. The fact is, user interface tools do not solve all the problems and the cost of maintaining user interface code can be huge.
Ian Horrocks, Constructing the User Interface with Statecharts, page 202
Horrocks also mentions that most books on the subject have examples based on electrical devices such as traffic lights, digital watches, the gears on a car and so on. Such examples don’t help developers who might want to use statecharts for User Interfaces, or to tackle complexity in general. The hope is that the statecharts.github.io project will provide guidance beyond what programming books of 1999 had available.
“Do the simplest thing that could possibly work”
Programmers are taught early on to implement “the simplest thing that could possibly work”, and rarely does a statechart fit that bill. The principle of the simplest thing is (as a lot of these principles are) misunderstood, and when the principle is correctly applied, then yes, a statechart might be defined as simpler than a lot of implicit booleans.
The easiest thing that could possibly work will always be a set of implicit booleans, switch statements etc, because by the very definition, it can possibly work, if you just get all of the if-statements correct, it will at some point, work. However, the step of simplifying is often forgotten, or skipped completely. It is in this step that one might introduce a statechart to simplify a complicated implicit state.
Anecdotal evidence suggests that the main reason for statecharts not being used is the YAGNI mindset, short for You Ain’t Gonna Need It. Complexity creeps in one boolean at a time, and along with that complexity comes bugs, but like the frog in the frying pan that doesn’t notice a slow increase in temperature, developers don’t notice the complexity creep.
When developing a component you start out with a simple model of its behaviour, and the different modes it has, so very early on, the component starts to gain a few booleans or perhaps an enum describing which behaviour it has, and which activity is going on. The booleans might be explicit, like
boolean requestIsActive, or it could be more implicit, such as the null-ness or “truthiness” of a variable:
var request = makeHttpRequest(...)
The component then starts making decisions on how to react to an event based on those explicit or implicit flags, e.g.
if (! requestIsActive) or
if (request == null). This functions pretty well on the scale of very small, wher you have two or perhaps three different behaviours. But pretty soon you will find a messy if-statement, or a switch statement, that modifies the state of various variables in order to try to keep them consistent.