Empryoempryo.beta
← Glossary
definition

Blast radius (code)

Blast radius (code) is the set of code that could be affected by changing a given symbol, file, or module — everything downstream that depends on it, directly or transitively. The larger the blast radius, the more places a change can break.

The term is borrowed from physics and incident response, where blast radius describes how far damage spreads from a single point. In software it answers a specific question before you touch anything: if I change this, what else has to change with it? For a function, that's its callers; for a module, its importers; for a database column, every query and serializer that reads it. A leaf utility that nothing imports has a small blast radius and is safe to refactor freely. A core type that 40 files depend on has a large one, and an innocent-looking edit there can cascade into failures several files away.

Blast radius is usually computed from the dependency graph. Direct dependents are the immediate importers or callers; transitive dependents are everything reachable by following those edges further out. Many teams approximate it with a simple count of incoming references (fan-in), which is cheap to compute and good enough to flag the high-risk hubs. The more precise version walks the full reverse-dependency closure and is what static-analysis and impact-analysis tools (and good code review) try to surface.

Two things make raw dependency edges an incomplete picture. First, dynamic dispatch, reflection, dependency injection, and string-keyed lookups create coupling that import graphs miss, so a static blast radius can undercount. Second, files that aren't connected by an import edge can still need to change together — a test and the code it covers, a schema and its migration. Co-change history (files that repeatedly appear in the same commits) captures this hidden coupling and is a useful complement to the static graph.

For developers, blast radius is mostly a risk-sizing and scoping tool. It tells you whether a change is a one-line fix or a multi-file migration, where to focus tests, and which edits deserve extra review. It is an estimate, not a guarantee: the real blast radius is only fully known once you make the change and run the type checker, the linter, and the test suite.