Deterministic Core, Non-Deterministic Shell

The piece presents a practical take on splitting programs into a deterministic core and a non-deterministic shell. The deterministic core contains the decision-making business logic and must produce repeatable outputs for the same inputs; the shell handles state, IO and integration with the outside world. Functional purity is one way to achieve determinism, but imperative constructs such as state machines can be equally deterministic when fed the same sequence of inputs - illustrated by comparing a pure add function to an AddMachine that accumulates the same inputs. Relaxing the requirement from “purely functional” to simply “deterministic” preserves the testability benefits while widening applicability across languages and performance constraints.

Concrete guidance follows: anything non-repeatable - unseeded RNGs, async or multithreaded operations, network and process communication, filesystem and database access, or OS time queries - belongs in the shell and should be lifted out of core logic or injected as parameters. In messy legacy code, deterministic fragments are common; treat refactoring like disk defragmentation by identifying, collecting and consolidating those fragments into testable cores. Hidden deterministic state machines can be surfaced and used to incrementally improve test coverage, reliability, and ease of modification.