What problems are easy to spot in a dependency graph?

Question

What are the things I should be looking for when I produce a dependency graph?

Or to put it another way, what are the characteristics of a good looking graph vs a bad one?

Edit: The context here is my first look at my assemblies in NDepend.

Answer 1

a dependency graph of what? classes? stored procedures?

cycles are bad...

Answer 2

If changing one dependency means you need to change a whole lot of others, it's bad.
But yea, some context could help.

Answer 3

I don't known what NDepend shows but artifacts that tend to get into many sections (particularly unrelated sections) of code would tend to be bad (IMHO). I've thought of that as "Cancer Code".

Answer 4

A speaker at a NFJS conference showed us some dependency graphs... One smell he pointed out was to look for things with relationships to different functional parts of your codebase. These likely break encapsulation.

Also I would look at the general complexity of each section.. ones with lines all over are suspects.

Answer 5

The biggest problem you can spot is definitely Dependencies Cycles. Here is an article on the subject: Controlling Dependencies

The dependency matrix is much more adapted than graph to spot cycles. Because a cycle avoid the matrix to be triangular.

The other ranges of problems are relative to your application structure: For example, is it normal that the UI uses directly the DB? or much worse, the DB depends on UI?

NDepend will also let you write rules to check for forbidden dependencies, like imagine that you dont want that the namespace UILayer uses the namsepace DataLayer, then write the Code Query Language rule:

WARN IF Count > 0 IN SELECT NAMESPACES WHERE IsDirectlyUsing "DataLayer" AND NameIs "UILayer"

Have a look at documentation here.