wbd-state-machines-and-flowcharts

Draw states as rounded rectangles labeled with noun-form conditions like PENDING, connect them with arrows labeled by the event that causes the transition, and mark initial and terminal states. Verify every non-terminal state has at least one exit transition.

A state machine models an entity's lifecycle, answering what conditions a thing can be in and how it moves between them. A flowchart models a process's logic, answering what to do step by step with decisions. If you say "the entity moves from state X to Y" use a state machine; if you say "first do X, then if Y do Z" use a flowchart.

Label transitions with the event that causes the change, such as payment_received or timer_expired, optionally adding guard conditions like [order_total > $50]. Never label transitions with destination state names, and avoid vague states like PROCESSING.

A non-terminal state with no outgoing transitions means instances can get permanently stuck, which maps to a real production bug like a stranded order. Walking each state and asking what events can occur exposes these dead-letter gaps before implementation.

Skip hierarchical states, parallel regions, and history pseudo-states for everyday team whiteboarding; the core 80 percent covers order lifecycles, ticket workflows, and retry logic. Formal notations like Petri nets matter mainly in academic or safety-critical contexts.