Executive Summary

Any workflow can be described as a finite state machine, but in practice teams often forget to model the states explicitly. Missing a state transition creates subtle bugs. The FaceTime privacy bug is a prime example: an action occurred in a call state where it shouldn’t have【80†L98-L100】. Explicitly drawing state diagrams can prevent such mishaps by forcing developers to enumerate all states and transitions up front.

The Hidden State in Software

By definition, a finite state machine consists of states and transitions. In enterprise software, there are countless states that aren’t obvious. For instance, a ticket can be ‘Open’, ‘Assigned’, ‘Resolved’, ‘Reopened’, etc. If any of these is missed, you get invalid transitions.

Often, when new features are added, developers code the "happy path" (the typical flow) and add a few conditionals. But as one observer puts it, this just increases complexity. Instead, the solution is to define the full state machine. Know your initial state, define every reachable state, and what events cause transitions. This discipline shines a light on hidden edge-cases.

David Khourshid analyzed a FaceTime bug: after adding a person to a call prematurely, audio streamed to the caller without acceptance. The core issue was a state violation: "something happened in a state it wasn’t supposed to happen in"【80†L98-L100】. In other words, the call was in a state (awaiting answer) where adding audio should have been blocked, but no check existed.

The FaceTime Lesson

The iOS FaceTime example shows how easy it is to introduce state bugs, even with full testing. The code looked correct for the usual case, but an unmodeled path caused a privacy breach. Khourshid notes that even thousands of tests missed it because the model was implicit【80†L98-L100】. His takeaway: modeling the logic with explicit states and transitions makes such bugs obvious before they manifest.

Imagine you draw the FaceTime call process as a state diagram: initial state is “Call Started (Awaiting Answer)”. The “Add Person” event should be disabled here. In a state diagram, that transition simply wouldn’t exist. By contrast, ad-hoc code allowed the invalid transition.

This demonstrates why we say we need state machines to the rescue: by formally modeling the allowed transitions, we prevent impossible flows. As Khourshid concludes, “we need to start getting in the habit of properly modeling our software. State machines to the rescue!”【80†L148-L150】.

Building Explicit State Machines

To use this in practice, teams can use UML state diagrams or statechart libraries. For each entity or workflow, list possible states and triggers. Visual tools or code-based state machines will then enforce those transitions.

For example, an order workflow might have states: New → Processing → Shipped → Delivered → Closed. Draw arrows for allowed moves. Any code that tries an undefined move should be considered a bug before it’s written.

Another case: a document might be Draft, PendingApproval, Approved, Rejected. If you don’t define what happens when it’s pending and someone edits it, you’ll get undefined behavior. Modeling forces the team to define 'on edit in pending, do X or forbid it'.

In short, treat every workflow like a state machine exercise. The upfront discipline catches holes. A quote summarizes it well: if something happens in a state it shouldn’t, the problem is clear. By explicitly mapping states, the team avoids those problems long before running the software.