Code dependency analysis is the practice of mapping the invisible graph of relationships between modules, services, libraries, and data flows in a software system — revealing which components depend on which, what breaks when something changes, and where coupling creates risk. It uses three complementary strategies: static analysis (parsing import statements and function calls), runtime analysis (observing actual service communication), and data flow analysis (tracing how data moves through the system). Unlike observability tools that show what's happening at runtime, dependency analysis reveals the code-level reasons components are connected and what would break if they were decoupled.
At Salesken, a seemingly simple payment service change cascaded into three other services because nobody had mapped the dependency graph. That incident cost us a weekend.
By Arjun Mehta
Code dependencies are the invisible graph running underneath everything your system does. When module A needs module B, and module B needs module C, and changing module C breaks something in module A eight hours later, that's a dependency you didn't know about. Most teams discover dependencies when they break something. Which is the worst possible time to learn about them.
I want to be specific about what I mean by "dependencies," because the word gets thrown around loosely and it covers three different things.
Service dependencies are how your microservices talk to each other. Service A calls Service B calls Service C. If Service B goes down, Service A still works but returns stale data. That's a dependency with operational impact. You need to know these because they determine your blast radius when things break.
Library dependencies are the packages you import. Your code depends on Rails, or React, or numpy. Libraries have versions, and version mismatches cause failures. You need to track these because they're security risks and they cause frustration when you upgrade one library and break another.
Data dependencies are the hidden ones. Your data warehouse depends on tables being updated in a specific order. Your cache depends on the database, but not the other way around. Your reporting system depends on data flowing through Pipeline A before it hits the reporting database. Data dependencies are usually invisible until someone changes the data flow and reporting breaks.
Most teams only think about service dependencies (because Kubernetes dashboards show them) and library dependencies (because package managers exist). Data dependencies usually stay invisible.
Here's why this matters: I can't estimate your feature accurately if I don't understand the dependency chain. If I think "add a filter" is isolated to one service, but actually it requires changes in three services because of how they depend on each other, my estimate is wrong. If I think migrating to a new data pipeline is straightforward, but actually it has a seven-step dependency chain to existing reports, the migration takes four times longer.
This is where most estimates go wrong. Not because engineers are bad at math. Because we can't see the dependency graph we're working in.
Let me give you a real example. We had a feature to add better logging to one of our services. The engineer scoped it at two days. Reasonable. But they didn't look at the dependency graph, so they didn't know that this service was called by eight other services, each of which had different expectations about log format. Turns out you can't change how one service logs without breaking the services that parse those logs. The feature became two weeks of work because of dependencies that weren't visible in the service itself.
If we'd had dependency visibility beforehand, the engineer would have said "oh, this touches eight services. Maybe we do this differently." Or "okay, this is actually a bigger project, let me estimate it properly." Instead, they assumed it was isolated and walked into a surprise.
This is true for all three dependency types. Service dependencies affect whether you can deploy independently or whether you need orchestration. Library dependencies affect your upgrade path and your security risk. Data dependencies affect your data reliability and your ability to change systems without breaking downstream stuff.
The problem is that dependencies aren't visible by default. They're implicit in the code. Service A calls Service B in its code, but you have to read the code or trace the network to know about it. Library B depends on Library C transitively, but you need a dependency tree to see it. Data Pipeline A writes to a table that Pipeline B reads from, but you need to trace data flow to know about it.
Most teams discover dependencies reactively. You change something, something breaks, you learn that there was a dependency you didn't know about. Then you document it. Then six months later someone new to the team changes the same thing, forgets about the dependency, and breaks it again. Every team I've worked at has this exact cycle.
The better way is to make dependencies visible before they're painful. Not as documentation (documentation gets stale). As actual maps generated from the code.
Here's what this looks like operationally: Before you estimate a feature, you look at a dependency map. You see which services it touches. You understand which data it moves through. You see which libraries it depends on. Your estimate actually reflects the work, not a guess.
When you're planning an infrastructure change ( - ) upgrading a library, migrating databases, changing data flows ( - ) you can see the full blast radius. You know exactly what else depends on that thing you're changing.
When an incident happens, you understand the dependency chain immediately. Service B is down. You look at the dependency map. You see that it takes down Services A, C, and D. You prioritize the recovery based on actual impact, not guessing.
This isn't theoretical. Teams that have dependency visibility make better technical decisions. They estimate more accurately. They have fewer surprise cascading failures.
The challenge is capturing dependencies at the scale of a real system. A medium-sized codebase has hundreds of services, thousands of libraries, complex data flows. You can't track this in a spreadsheet. You need a system that generates these maps automatically from the code, and keeps them current as the code changes.
Most teams try to maintain dependency graphs manually. It doesn't work. The graph is complicated. People forget to update it. It diverges from reality. The moment your dependency map stops reflecting reality, it becomes a liability instead of an asset.
The best teams I've worked with have tooling that generates the dependency map from the actual code. Static analysis of your services to find who calls who. Tracing your imports to build a library dependency tree. Analyzing your data pipelines to understand data dependencies. The map stays current because it's derived from the source of truth.
This is why PM visibility into dependencies matters too. A PM who understands that Feature X depends on Service Y will not commit to Feature X the day after a major incident took down Service Y. But if the PM can't see dependencies, they'll commit to it every time.
Engineering leaders use dependency maps to understand technical risk. You can see which services are bottlenecks. You can see which libraries are widely used and therefore critical to keep healthy. You can plan refactoring and infrastructure work based on actual system structure, not guesses.
The real value of dependency visibility is that it makes the invisible visible. Dependencies will exist whether you track them or not. You get to choose whether you discover them proactively or reactively.
Frequently Asked Questions
Q: Can we just use git history to find dependencies? Git history tells you what changed, not what depends on what. You can see that someone modified Service A and Service B broke, but git won't tell you why they're connected. You need actual code analysis — dependency mapping tools that parse imports, function calls, and code dependencies at the source level.
Q: Isn't this just what a service mesh or observability tool does? Service meshes and observability tools show you what's happening at runtime. They show you that Services A and B are communicating. They don't show you the code-level reasons they have to communicate, or what would break if you decoupled them. Different view, different tool.
Q: What happens if the map gets out of sync with reality? That's why you need automatic generation, not manual maintenance. A map that's auto-generated from the code can't get out of sync because the code is the source of truth. A map that someone maintains in a wiki will get out of sync in two months guaranteed.
Related Reading
- Code Dependencies: The Complete Guide
- Dependency Mapping: A Practical Guide
- Software Architecture Documentation: A Practical Guide
- C4 Architecture Diagram: The Model That Actually Works
- Code Refactoring: The Complete Guide to Improving Your Codebase
- Knowledge Management System Software for Engineering Teams