How to assess the blast radius before changing any code

Every Change Has a Blast Radius

Blast radius is the scope of potential impact when you change a piece of code. Changing a function used in 50 places has a larger blast radius than one used in 2. Measuring it before touching anything prevents breaking changes you didn't anticipate.

Measuring Blast Radius

# Find every file that imports or calls your function
rg "formatCurrency" src/

# Count usages to quantify impact
rg -c "formatCurrency" src/ | sort -t: -k2 -rn

# Output example:
# src/components/OrderSummary.jsx:5
# src/components/InvoicePDF.jsx:3
# src/utils/reports.js:8
# Total: 3 files, 16 usages

Types of Changes and Their Risk

• Adding a new optional parameter — low risk; existing callers unaffected
• Changing a return type — high risk; every caller must handle the new shape
• Renaming a function — safe only if you update all call sites atomically
• Changing database schema — requires migration; affects all code reading that table

// Low blast radius: add optional param with default
function formatCurrency(amount, currency = 'USD') { ... }

// High blast radius: change return from number to string
// Before: returns 1299 (number)
// After: returns "$12.99" (string)
// Every caller that does math on the return value breaks

If the blast radius is large, write your change as a non-breaking addition first, migrate callers one by one, then remove the old behavior. Never do a large-radius change in a single commit.