A tangled nightly payroll routine can be flattened mechanically into one loop over a state variable — when is that transformation the right call for the team?
answer
- behaviour-preserving, not comprehension-preserving
- a scaffold, rarely a destination
- capture a baseline before touching it
- many structured equivalents exist, choose one
- keep it only where the states are real
basics
~20 sRarely as a destination, often as a scaffold. The flattening is behaviour-preserving and mechanical, which is its whole value on code nobody dares touch, but it moves the structure into a variable, so it must be followed by extracting and naming real regions.
solid answer
~50 sThe transformation's value is that it is **mechanical and behaviour-preserving**: it can be applied to a routine nobody understands, which is exactly the situation where hand-restructuring is most dangerous. Its cost is that the control structure now lives in the values of a state variable, so every reader simulates rather than reads. So treat it as a scaffold: flatten to get a safe footing, capture a baseline of real outputs first, then find the parts that genuinely are a sequence, a choice or a repetition, extract them behind names, and keep going until the state variable has nothing left to do. Keep the flattened shape as the destination in one case only — when the routine really is a state machine and the states carry domain names. The theorem promises a structured equivalent exists; choosing which one the team lives with is engineering.
go deeper
The takeaway is that a rewrite preserving behaviour is not automatically an improvement; ask who has to read the result.
Be able to explain why a mechanical transformation is safe on code nobody understands, and what it costs the next reader.
Show the sequencing: capture a baseline, flatten only if hand-restructuring is too risky, then extract and name regions until the control variable is gone.
This is a standard-setting call. Decide when teams may flatten, require the extraction half to be funded, and name the one case — a genuine domain state machine — where the dispatch shape is allowed to stay.
## What the transformation actually gives you Flattening replaces tangled flow with one loop over a multi-way selection on a control variable. Three things are true of it, and all three matter to the decision: - **It preserves behaviour.** The computed result is unchanged, which is what makes it usable on a routine with no tests and no surviving author. - **It is mechanical.** It needs no understanding of what the routine does, so it carries none of the risk that comes from a human deciding what a confusing branch "obviously meant". - **It is not a simplification.** Nothing has been removed. The arrows have become assignments, and the routine is usually longer than it was. ## What it costs - **Reading becomes simulation.** To learn what can follow a step, a reader must find every assignment to the control variable, instead of following one edge. - **Locality is lost.** Any arm can in principle hand control to any other, so the blast radius of editing one arm is the whole routine. - **Review gets harder, not easier.** A diff inside one arm looks small and may change the routine's path entirely. - **The change is enormous in the history.** Essentially every line moves, so blame and bisect over that routine become much less useful. - **It can hide, rather than expose, dead paths.** A chunk unreachable in the original becomes an arm that merely never gets selected, which is less visible. ## When it is the right call 1. **The routine is high-risk and poorly understood.** Money moves, an audit trail is produced, the run happens once a night and a bad run is expensive to undo. Here the mechanical guarantee is worth more than the readability it costs, because the alternative is a human guessing. 2. **You have captured a baseline first.** Characterisation outputs from real runs, kept as the thing the rewritten routine must reproduce. Without that, "behaviour-preserving" is a claim about the transformation rather than a fact about your application of it. 3. **You have committed to the second half.** The flattening is only worth its cost if extraction follows: find the collapsible regions, name them, delete the states they absorbed. A team that stops at the scaffold has made the routine worse and called it a refactor. 4. **The work is bounded and owned.** A half-finished flattening — part named regions, part live state variable — is the worst of both shapes and should not survive a single iteration. ## The one case where it is the destination When the routine genuinely *is* a state machine — a protocol, a resumable batch, a workflow with named stages that an operator talks about — the control variable is not an artefact. It names something real, and the dispatch loop is then the honest shape: the states get domain names, the transitions become a table someone can review, and the flow a reader has to simulate is the flow the domain actually has. Note the direction of the test: the shape is justified by the domain having states, never by the transformation having produced states. ## Setting the standard | situation | the call | why | |---|---|---| | risky legacy routine, no tests, no author | flatten as a scaffold, then extract | mechanical safety now, structure later | | routine is understood, tests exist | restructure directly, region by region | the scaffold costs readability it does not need to spend | | domain genuinely has named states | dispatch loop as the destination | the variable names something real | | hot path under scrutiny, read weekly | avoid the scaffold entirely | every reader pays the simulation cost | | tool-generated code nobody reads | leave it | the reader cost is hypothetical | ## The failure mode to watch The predictable failure is stopping at step one and declaring victory, because the mechanical step is fast and satisfying and produces a diff that looks like progress. The second half — deciding which parts of the routine are genuinely a sequence, a choice or a repetition, and naming them — is slow, needs understanding, and produces small diffs. That asymmetry is what makes this a lead's decision rather than an individual's: someone has to fund the unglamorous half and refuse the transformation where nobody will. The second failure is treating the result as evidence. A behaviour-preserving rewrite of a routine tells you nothing about whether the routine was ever right. If the nightly run has been computing a deduction incorrectly for two years, the flattened version computes it incorrectly in a tidier arrangement.
- The routine has no tests at all. What would you capture before starting?A characterisation baseline: the actual outputs of real runs over a representative range of inputs, including the failure and edge cases the routine hits in practice. It is not a specification and does not claim the behaviour is correct — it claims only that the rewrite reproduces what is there today, which is exactly what a behaviour-preserving transformation promises.
- Halfway through extraction the work is deprioritised. What have you left behind?The worst of both shapes: part of the flow in named regions, part still encoded in a live control variable, and a reader who must hold both models at once. If the work cannot be finished, it is better not to start the flattening, or to timebox it to one region and stop at a coherent point.
- Does the structured program theorem settle this decision?No. It guarantees that a structured equivalent exists, and the mechanical flattening is a proof of that. It says nothing about which of the many structured equivalents is worth living with, and that choice — readability, review cost, who maintains it — is the entire engineering question.
saying these in an interview costs you the question
- Treats the mechanical flattening as the finished refactor
- Assumes the theorem picks the structured version worth having
- Rewrites a money-moving nightly routine with no captured baseline
- Judges the result by line count rather than by the reader
- Thinks a dispatch variable always names a real domain state
- Believes a behaviour-preserving rewrite shows the routine was correct