Steps you can check

Think of it when a task is a long run of similar edits, such as a rename across many files or a move of many records.

In everyday life

Like counting stitches at the end of every row of knitting, not only when the scarf is done. A dropped stitch found at once costs one row; found at the end, it costs the scarf.

One case

An agent renames a function that 40 files use. It works in 8 steps of 5 files and runs the tests only once, at the end. 23 tests fail, from three different steps, and now the agent must search all 40 files to find which edits caused which failures.

Three steps broke tests; the one check came at the end
The case, cell by cell1 cell = 1 step of 5 files
Failing tests, if all is well
00000000
Failing tests, had it checked each step
003339923
Failing tests at the one check
23
Steps that broke something
3
A check after every step would have stopped the work at step 3.

Every case

A break found right after the step that caused it is cheap: the cause is in the last few lines. A break found after a batch is buried, and more work already sits on top of it. The cost of a mistake grows with the distance between making it and seeing it. So each step is a bracket: a known-good state, one change, one check, and only then the next step.

The word

Engineers call this

verifiable unitsSplit big work into small steps that each end in a state you can check. Check each step before you start the next one.

End every step greenPassing. A check that passes is shown green; a check that fails is shown red. before you take the next one. Then a failed check points at the last step, not at the whole job.

Where this idea leads

Skills that encode it

  • principle-sequence-verifiable-units pstackEach unit is a bracket: a known-good state, one change, run the check, then go on. Never advance past red.
  • principle-build-the-lever pstackA script does the edits and the check the same way every time, so the check after each step is nearly free.