Disclaimer: I'm offered a free license for NDepend 2.0
Ok, first sorry for the disclaimer, but I think it's best to have fully clarification and transparency towards my readers so they can determine by themselves if what they read is OK, and from now on I'll put such a disclaimer in a post if I feel it's necessary.
Now that's out of the way, I'd like to point you to the fact that NDepend v2.0 has been released. NDepend is a metrics toolkit, it allows you to get fine-grained reporting about all kinds of metrics of your software. NDepend is a static analyzer, which means it analyzes the compiled code, not a running instance.
Sofware metrics are very important, they allow you to get insight in the health of the software you've written: which parts depend on which other parts, which part is very complex and likely a spot which will become a maintenance burden later on etc. etc. Though, what's equally important is the semantic meaning of all these metrics, the numbers produced by a metrics toolkit, like NDepend. In other words: what's the level 0 and what does '10' mean on the scale used and is it bad or good?
At the Software Architecture Workshop (SAW) in Arosa we discussed this topic as well, and we sort of came to the conclusion that when using a metrics tool, it's very important to understand what the numbers mean, not only in a general context, but also in the context of your own software. For example a method with a high number for Cyclomatic Complexity doesn't necessarily have to be a bad method, for example if you know that it's the best solution for that particular piece of logic. A good way to get proper insight is to analyze software of which you find it's of very good quality, and the code is comparable (e.g. does the same thing, so don't compare a 3D engine with a business application). If you then compare the metrics of your own code with the metrics found in the software of high quality, you can get a bit of insight if the values you get back are really bad or really good. Though always realize that you've to be sure you can place the metrics into context.
Once you realize what the power of metrics are, and you understand how to judge them in the context of your code, a tool like NDepend can give great value to get insight in the quality and health of the software you wrote.
Metrics don't always have to be numbers and you can use them for things you wouldn't realize up front. Take for example obfuscation. Often people complain that an obfuscator isn't as good as they would have hoped. They don't realize that an obfuscator needs as much private/internal types/methods/properties as possible, as these can be renamed etc. without breaking external code. A tool like NDepend can find the methods, properties and classes which don't really have to be public. You then can make these internal or even private. If you then re-run the obfuscator of choice, you'll see that the obfuscated result is much better.