Tag: complexity
Complexity Matters - Baseball's New Strike Zone
Posted by bsstahl on 2026-09-27 and Filed Under: development
TL;DR
MLB's hybrid ABS challenge system is a disaster for baseball because it violates one simple rule:
Complexity that does not facilitate the primary objective is damaging to the system.
This is true with ABS for 2 reasons:
- It adds unnecessary complexity to what should be a simple decision: each pitch should resolve immediately as either a ball or a strike.
- It adds non-baseball strategy to the game, forcing players and managers to think about challenge timing and inventory instead of playing baseball, while still not solving the underlying problem: baseball games should be decided by the athletic skill of the players.
Introduction
For over a century, every baseball pitch was governed by a simple model with two possible outcomes: ball or strike. The binary call provided a clarity that was easily understood by everyone on the field and off. When the umpire signaled, the result was unambiguous, even when the call was wrong. Fans might grumble about blown calls, but the system itself was not questioned. Its simplicity required little mental effort to follow and left little room for confusion or debate. That was the baseline: a shared understanding of pitch in, call out, with the rulebook treated as final. MLB's new hybrid approach creates two problems: it adds unnecessary complexity to a simple ball-or-strike decision, and it introduces a non-baseball strategy around challenge timing and inventory.
Technology Arrives, But Only Halfway
Major League Baseball, long in pursuit of the perfectly called game, eventually turned to technology for help. Events like Armando Galarraga's near-perfect game in 2010, along with the apparent success of the replay challenge system, may have made a challenge-based ABS (Automated Balls and Strikes) model seem more attractive, even though ABS is a different system from replay challenges, with different mechanics and implementation. Automated systems like ABS offered a more accurate and consistent strike zone, a modern response to the limits of human judgment. MLB did not fully hand the decision over to automation, however. Instead, it chose a hybrid approach: umpires still make the initial call, and those calls can then be challenged and reviewed by ABS. The result is not a better version of the old system; it is a layered process that preserves human failings while adding machine oversight. That layering may improve accountability, but it also adds complexity, and the challenge step can make the experience harder rather than simpler to follow.
It Still Lets Bad Calls Decide Games
If the objective of adding ABS is to attempt to eliminate times that a bad call changes the outcome of a game, the challenge system fails because access to a correction is limited. A player has to decide which calls are important enough to challenge, while preserving challenges for situations that might matter more later. That means an incorrect call, even one that could ultimately determine the outcome of a game, can remain in place not because ABS cannot identify it, but because that player cannot risk one of his team's limited challenges on it, or the team has no challenges remaining. This is exasperated by the fact that review requests must be made instantly, without reflection or aid, and by the players themselves, with varying levels of experience and reliability in these areas.
This turns accuracy into a resource-allocation problem. A close call in an early inning may be wrong, but challenging it could leave a team without protection in a later, higher-leverage situation. A consequential call can therefore stand while a less important call is reviewed, simply because the available challenge inventory has to be managed over the course of the game. The system still permits the very outcome it was supposed to prevent: a game being decided by an uncorrected bad call.
The limitation is not just an implementation detail. Once correction depends on inventory management, the system cannot treat every pitch according to the same standard. It asks participants to optimize when to seek correctness instead of making every call correct by default. That weakens the primary objective while creating the non-baseball strategy and additional complexity discussed below.
The State-Machine Tangle: When a Strike Isn't Just a Strike
Systems are shaped by the states they recognize and the transitions between them. For a hundred years, baseball's model was elegantly sparse. Every pitch lived in one of two states: a ball or a strike. Nothing to memorize, nothing to manage. But with the introduction of ABS challenges, things quietly got more complicated. Now, what used to be a simple call must traverse a web of possible verdicts before it's settled.
Instead of the old binary, the hybrid model introduces six to eight distinct states, depending on how strictly states are counted. These include called, unconfirmed, validated, and final ball-or-strike outcomes, each with its own implications for the game and its participants.
Here's the twist: none of this scaffolding exists for the sake of baseball itself. These aren't states that matter to the nature of pitching or hitting, but layers imposed to manage and ration access to truth.
To appreciate just how much complexity the ABS system introduces, compare it to the pre-ABS state machine where there were only two possible destinations for every pitch:
stateDiagram-v2
state "Ball" as Ball
state "Strike" as Strike
[*] --> Ball: Ump Calls Ball
[*] --> Strike: Ump Calls Strike
With the new ABS hybrid system, MLB has introduced a set of intermediate states and transitions that eventually result in the same Ball or Strike call. The diagram below illustrates the expanded system:
stateDiagram-v2
state "Called Ball" as Initial_Ball
state "Validated Ball" as Validated_Ball
state "Unconfirmed Ball" as Unconfirmed_Ball
state "Ball" as Ball
state "Called Strike" as Initial_Strike
state "Validated Strike" as Validated_Strike
state "Unconfirmed Strike" as Unconfirmed_Strike
state "Strike" as Strike
[*] --> Initial_Ball: Ump Calls Ball
[*] --> Initial_Strike: Ump Calls Strike
Initial_Ball --> Validated_Ball: Catcher Challenge<br/>Unsuccessful
Initial_Ball --> Validated_Strike: Catcher Challenge<br/>Successful
Initial_Ball --> Unconfirmed_Ball: No Challenge Issued
Initial_Strike --> Validated_Strike: Batter Challenge<br/>Unsuccessful
Initial_Strike --> Validated_Ball: Batter Challenge<br/>Successful
Initial_Strike --> Unconfirmed_Strike: No Challenge Issued
Validated_Ball --> Ball
Unconfirmed_Ball --> Ball
Validated_Strike --> Strike
Unconfirmed_Strike --> Strike
A Live Counterexample: WPBL
The Women's Pro Baseball League (WPBL), operating out of Springfield, Illinois, offers a useful contrast. The league does not use MLB's ABS challenge layer, and the result is a cleaner game flow: each pitch resolves immediately into the same two-state model baseball has always used.
That simplicity matters. Without challenge inventory, review choreography, and overturn bookkeeping, players and fans can focus on pitch execution, sequencing, and situational strategy instead of state management. In systems terms, WPBL avoids adding intermediate states that do not improve the core interaction.
If the goal is to preserve baseball as a game of rhythm and readable outcomes, WPBL shows that the simpler model is not outdated—it is often the better design.
Complexity has a Cost, and not Just in Baseball
Complexity is not just a technical property; it is a user-experience cost. Every additional state in a system introduces more transitions, and every transition introduces another chance for hesitation, disagreement, or error. What used to be instantaneous and final now carries conditional logic: who can challenge, when they can challenge, whether it succeeds, and how that outcome is interpreted in context. Even when the final output is still only ball or strike, the path to that output has become tangled.
In system design, this is a familiar pattern. State growth tends to produce edge cases, and edge cases demand rules. Rules then require timing constraints, exception handling, and social coordination among participants. In baseball terms, that means more signaling, more pause points, and more moments where participants are managing process instead of playing the game. In software terms, it is state explosion: a known source of fragility, cognitive load, and surprising behavior.
The important point is that this cost is not neutral. Added complexity reshapes attention. Players begin optimizing for challenge timing and inventory management. Fans must parse whether they just saw an ordinary call, a provisional one, or a reviewed and overturned outcome. Umpires and broadcasters inherit additional interpretive overhead. None of this directly improves the core act at the heart of the game: pitcher throws, batter reacts, umpire (or system) resolves.
When complexity accumulates faster than value, the system becomes harder to trust, harder to follow, and harder to maintain. That is the descent: not a dramatic failure, but a gradual shift where procedural scaffolding starts to overshadow the thing it was meant to support.
A Meta-Process Emerges
Once a system introduces optional review states, participants stop engaging only with the core activity and start managing the review mechanism itself. That is exactly what MLB's challenge-based ABS model creates: a second game layered on top of baseball. The pitch is no longer just a contest between pitcher and hitter; it is also a resource decision about whether this specific moment is worth consuming part of a limited challenge budget.
From a DDD (Domain-Driven Design) perspective, this is a boundary problem. The core domain of baseball at this decision point is pitch adjudication: was it a ball or a strike? The challenge mechanism introduces a separate supporting subdomain that is orthogonal to that core judgment and includes tasks like managing challenge inventory, timing escalations, and review strategy. Once that subdomain exists, participants optimize it, and system attention shifts away from the primary domain behavior.
For catchers, this means constant triage. A close miss that could steal a strike might be worth a challenge early, but using one too soon can leave the defense exposed later when leverage is higher. Hitters face a mirrored decision: protect an at-bat now, or save the challenge for a later pitch sequence that might matter more. Managers, meanwhile, are pulled into inventory tracking. Having to count available challenges, anticipate future high-leverage spots, and balance immediate correctness against late-game optionality. Players are judged not just on their ability to do their job as a baseball player, but as a maker of these snap decisions as well.
Fans and broadcasters inherit this complexity too. Instead of processing a straightforward call, they must now interpret whether a pitch was merely called, left unchallenged, or challenged and either upheld or overturned. The vocabulary and timing of the game shift from direct outcomes to procedural states. Attention moves from "what happened on that pitch?" to "what state is this call currently in?" and "where do we stand with the number of opportunities we still have to challenge?".
This is the key consequence of hybridization: once process becomes strategic it begins to shape behavior. The system no longer just adjudicates baseball, it influences how baseball is played, watched, and discussed in real time. That is the meta-game, an added layer of state management that did not previously exist, and that competes with the game itself for cognitive bandwidth.
The Simpler, Better Alternative
The strongest alternative is not partial automation but full automation at the point of the strike-zone call. In such a model, ABS determines every ball-or-strike decision, and the home-plate umpire communicates that result immediately while continuing to handle all other on-field responsibilities at the plate.
This preserves what matters most from both perspectives. From a correctness standpoint, each pitch gets a consistent, machine-judged strike-zone ruling. From a game-flow standpoint, there is no challenge inventory, no review choreography, and no intermediate call states to track. The decision remains binary and immediate: each pitch resolves once, in real time, as ball or strike.
Crucially, this approach removes the hybrid complexity rather than managing it. There are no provisional outcomes waiting for escalation, no strategic overhead about when to challenge, and no meta-process competing with the core contest between pitcher and hitter. The system does one thing, adjudicate the zone accurately, and does it the same way every time.
In systems terms, full ABS at the decision point is the minimal-state design that still achieves the primary goal. It improves consistency and reliability of the system without expanding the state machine, and it gives baseball a cleaner architecture: deterministic calls, lower cognitive load, and fewer failure points in high-leverage moments.
In engineering terms, this is the difference between replacing a component and wrapping it in control scaffolding. Hybrid ABS wraps a flawed step with exception paths, escalation logic, and resource management rules. Full ABS replaces the decision component outright and keeps the interface simple: one input event (pitch), one authoritative output (ball or strike), no secondary workflow. That is classic complexity control, solve the core reliability problem at the source, minimize state, and avoid layering process where determinism will do.
Complexity Is a Choice
The deeper lesson here reaches far beyond baseball. Hybrid systems are often framed as pragmatic compromises, but they frequently inherit the weaknesses of both approaches while adding a new layer of coordination overhead. In MLB's challenge-based ABS model the goal was to improve strike-zone accuracy, yet the chosen implementation expanded the state machine, increased cognitive load, and introduced a meta-process that competes with the game itself.
From an engineering perspective, this is a familiar failure mode. When a core function is unreliable, teams often add exception paths, overrides, and escalation logic around it instead of replacing the weak component directly. The result can be locally rational but globally complex: more states to track, more transitions to test, and more ways for behavior to drift from intent.
The alternative is disciplined simplification. Define the primary objective, then choose the architecture with the fewest moving parts that reliably achieves it. For balls and strikes, that means deterministic ABS calls delivered in real time, with no challenge layer and no procedural detours. More generally, it means designing systems where correctness is built into the core path, not bolted on through secondary workflows.
In DDD terms, robust systems protect the core domain and resist importing process-heavy subdomains that compete with core outcomes.
Complexity is not an inevitable byproduct of progress, it is a design decision. And when accuracy and consistency are the objective, the system with the fewest states usually wins.
