Reading a dependency graph: finding the modules that will hurt you

Most teams see their dependency graph exactly once — in a slide, during an architecture review, looking impressive and telling no one anything. Read properly, it's a map of where change is expensive.

Look for the hubs

Every graph has a few nodes that everything points to. A shared utils module, a core model, a base class. These hubs have high fan-in: lots of code depends on them. That's not inherently bad — shared code is the point — but it means a change to a hub has a large blast radius. Break the hub and you break everything downstream. Hubs deserve stability, strong tests, and careful versioning.

Look for the tangles

Healthy architecture flows one direction: UI depends on services, services depend on data, not the other way around. When you see cycles — module A imports B imports C imports A — you've found a tangle. Cycles make code impossible to test in isolation, hard to reason about, and resistant to change. They're where "I'll just refactor this quickly" turns into a two-week yak-shave.

Look for the islands

Clusters that barely connect to the rest are usually a good sign — they're well-encapsulated, and you can change them without fear. When a feature is one tight island with a single edge to the rest of the system, that's a boundary you can trust.

From picture to priority

The value isn't the visualization; it's the prioritization it gives you:

• Hubs → invest in tests and stability.
• Cycles → break them before they metastasize.
• Islands → safe to move fast.

Impact renders your architecture as an interactive graph and computes blast radius per module, so "which change is risky" stops being a gut call.