Smallest change

Think of it when a fix starts to touch files that the problem never touched.

In everyday life

Like a tailor asked to take in a waist who also recuts the collar and the sleeves. The waist now fits, but every seam needs checking, and one of them is wrong.

One case

A booking site shows the wrong time zone in one confirmation email. The fix needs 4 lines in one file, but the developer also renames variables and reformats five other files, and the change grows to 900 lines. The reviewer skims it. One rename breaks the cancel button, and for 2 days customers cannot cancel a booking.

The fix needed 4 lines; the change touched 900
The case, cell by cell1 cell = 1 file
Lines the fix needed
400000
Lines the change touched
4180160140216200
Lines changed
900
Lines the fix needed
4
The break hid in the cancel file, one of five files the bug never touched.

Every case

Every extra line is a line someone must read, test and trust. A big diffThe lines a change adds and removes, shown side by side. Reviewers read the diff to see what changed. hides its one risky line among many harmless ones, so review gets weaker exactly when the change needs it most. When something breaks, a small change points at its own cause; a big one makes you search. AI agents do this often: asked to fix one thing, they tidy everything nearby.

The word

Engineers call this

minimal diffChange only what the problem needs. Fewer changed lines means less to review, less to break and less to undo.

Fix the case that happened, in the fewest lines that fix it. Put any cleanup in a separate change.

Where this idea leads

Skills that encode it

  • principle-laziness-protocol pstackMinimize the diff: make the smallest change that solves the problem. Fewer lines beat “elegant” boilerplate.
  • full-send tstackFinish with the smallest change that works: fix the case that happened, not every case that could.
  • sol-loop tstackMake the most minimal changes to answer the reviewer, and decline findings that would grow the scope.