Visualization is a powerful mental technique, but visual aids can only really represent a few dozen things before they become as complicated as the thing you were trying to understand in the first place.
And when analyzing messy state diagrams, it’s not just the states we’re trying to visualize, but the lines connecting the states (the “edges” connecting the “nodes,” in graph-theory terms). We can only visualize a few dozen of those, and that typically means we can visualize only a handful of states at a time.
It looks great in a slide deck, but it only works in trivial examples where you don't need it; it fails in complex environments where you need it the most.
I disagree especially because statecharts solve this with hierarchical states. You draw and think about a substate on its own, without all the higher-level complexity. Then once ready you can include it in any subsequent layer - hence it’s composable and reusable.
Take a look at the “unclustering” section of the statecharts paper.
Yes. I can this a self describing system. When the code or config can be used to generate reference materials, at run time or build time, to make understanding the system easier.
Typically you don’t need to refere to these diagrams and outputs very often, but they are useful for:
- on boarding new people to the team
- deep reasoning when debugging or analysing a problem
- putting on the board during a design session
And when analyzing messy state diagrams, it’s not just the states we’re trying to visualize, but the lines connecting the states (the “edges” connecting the “nodes,” in graph-theory terms). We can only visualize a few dozen of those, and that typically means we can visualize only a handful of states at a time.
It looks great in a slide deck, but it only works in trivial examples where you don't need it; it fails in complex environments where you need it the most.