Know what it can break

Think of it when you decide how carefully to check a change, and how many places to check.

In everyday life

Like changing one light bulb compared with closing a building’s main water valve. Both take one turn of the hand; one affects a lamp, the other every tap upstairs.

One case

A bank ships two one-line changes on the same day. One fixes a typo on a help page. The other changes the date format in a shared helper that 40 services use. Both get the same 2-minute review, and the helper change breaks statement downloads in 6 services.

Know what it can break
The ideaKeep it contained
Know what it can break

How much can break if a change is wrong. It sets how carefully you check the change.

Keep it contained, Habits

Every case

The size of a change says little about its risk. One line in code that many things depend on can break all of them, while 500 lines on one isolated page can usually break only that page. The risk lives in what depends on the changed code, and the diffThe lines a change adds and removes, shown side by side. Reviewers read the diff to see what changed. does not show that. So find what reads, calls or runs this code before you decide how hard to check it. Where you can, shrink the radius on purpose: ship to a few users first, or behind a switch.

The word

Engineers call this

blast radiusHow much can break if a change is wrong. It sets how carefully you check the change.

Before you ship, ask what this change can break. Check in proportion to that answer, not to the size of the change.

Where this idea leads

Skills that encode it

  • blast-radius pstackFinds what a change breaks somewhere else, and proves the one fact its safety depends on by running code.
  • to-tickets Matt PocockSizes the batches of a wide refactor by blast radius, so each batch can stay green on its own.