measure-before-you-widenlisted

# Measure before you widen ## Purpose Having fixed something in one place, the eye finds the next place that calls the same routine and the mind supplies "same defect". That inference is cheap and often wrong, and acting on it costs the most expensive kind of change — a second format version, a second public API adjustment — for a problem that may not exist there. Measuring the candidate first is a few minutes of work that either produces the evidence a reviewer will ask for, or saves the change entirely. Either outcome is worth more than the assertion, and the probe itself puts you inside code you had no reason to open. ## When to use - A fix has landed and a neighbouring component shares the call, the parser, the offset arithmetic, or the file layout. - Someone (including you) says "consistency argues for doing both". - You are about to write "the same problem exists in X" in a PR body or an issue. - A third commit is queued behind two that measured well. ## When NOT to use - The change is mechanical and carries no risk — a renamed symbol, a corrected comment, a javadoc fix. Measuring a typo is theatre. - The neighbour is *identical* code, not merely similar: a copied file, a generated variant. Then it is the same defect by construction, and the work is deduplication. - The candidate cannot be measured without building the fix first. Say that plainly rather than pretending a number exists. ## The practice (checklist) - [ ] **Re-run the original measurement**