PAPER
When Tools Become the Problem
A good tool applied to the wrong problem makes the system worse.
State machines are powerful. They model lifecycle, enforce transitions, and make complex processes explicit. Used correctly, they bring clarity to systems that evolve over time.
Used incorrectly, they introduce complexity where none is required.
Not every decision is a process.
Some are just decisions.
The Difference Between a Decision and a Process
Some problems are decisions. They take inputs and produce an outcome. Given the same inputs, the result should always be the same.
Other problems are processes. They unfold over time, move through states, and require transitions that must be enforced.
These are different categories of problems. They require different tools.
A function evaluates a decision. A state machine models a process.
When these are confused, systems become harder than they need to be.
How This Goes Wrong
It usually starts with a useful abstraction.
A state machine is introduced to solve a real problem. It brings structure to a workflow that needed it. Transitions become explicit. Behavior becomes easier to reason about.
Then it spreads.
Instead of asking whether a problem is a decision or a process, the same tool is applied everywhere. Simple evaluations are turned into stateful flows. Deterministic logic becomes distributed across transitions. What should have been a single evaluation becomes a multi-step lifecycle.
This feels consistent. It is not correct.
The Cost of Over-Modeling
When a decision is modeled as a process, complexity is introduced where none is required.
State now has to be stored, retrieved, and maintained. Failures must account for partial progress. Retries become more complicated because the system must resume from an intermediate state rather than re-evaluate from inputs.
The logic becomes harder to see. Instead of reading a function and understanding the outcome, you have to trace transitions across multiple states to determine what will happen. The system is no longer obvious.
Changes become more expensive. Updating a decision now means modifying a lifecycle. Adding a condition requires touching multiple transitions rather than adjusting a single evaluation.
None of this adds value if the problem was never a process to begin with.
What Simplicity Actually Looks Like
A decision should remain a decision. Inputs go in. An outcome comes out. The logic is explicit, testable, and deterministic. There is no intermediate state because there does not need to be.
Processes should be modeled as processes. They carry state because they evolve over time. They require transitions because order matters. They need visibility because failure can occur at any step.
Clarity comes from using the right abstraction for the problem, not from using the same abstraction everywhere.
Why This Happens
This is not usually intentional. It comes from uncertainty.
When a problem is not well understood, engineers reach for tools that feel expressive. State machines, workflows, and orchestration patterns create the impression of handling complexity.
In reality, they often hide a lack of clarity about what the system needs to do.
Overengineering is rarely about ambition. It is about uncertainty.
The Boundary That Matters
The distinction is simple.
If the outcome can be determined entirely from the inputs, it is a decision. If the outcome depends on progression over time, it is a process.
Confusing the two introduces complexity that does not need to exist.
What Over-Modeling Produces
Systems built this way become heavier than the problems they solve.
What should have been a function becomes a workflow. What should have been immediate becomes staged. What should have been obvious becomes something that requires tracing through multiple steps to understand.
The system still works. It is just harder than it needs to be.
Continue reading
Papers