What metrics do you really use?

Greetings all,
Shortly I will be presenting to my graduate course in Object Oriented Systems Development a discussion on metrics (sort of being team taught between the professor and myself) - I have my short list of must have metrics on a project, he has his (mostly the same) - and that is why I am posting - I was hoping for more variance.
So any of you that are involved with OOSD would you be kind enough to post what metrics you gather - and what metrics you (or your team) really use.
Thanks in advance.
-steve

I'm on an XP team whose nightly metrics report includes counts of (cutting and pasting

Unit tests

Java source files

Java classes

Java total source lines

Java unit-test source lines

Java non-test lines

Total code lines analyzed

Unexecuted lines

Test coverage

Passing functional tests

Failing functional tests

Unexpected failures

Skipped functional tests

Uses of "instanceof"/KLOC

The ones we actually use are unit test coverage percentage, functional test pass/fail, and especially "Unexpected failures". Our functional test framework lets you mark a test as "I know this one doesn't pass yet." Unexpected functional test failures are ones that used to work and are now broken.
We used to look at unit test count and line count a lot, earlier in the project, to see how it grew and pat ourselves on the back. We never think about those anymore.

Ernest, which coverage tool you guys use?

HERE are some metrics we tracked regarding project size (scope), velocity and progress. High visibility tracking and reporting make it hard to cover up progress problems with spin!
There's a whole science around defect tracking, when they were introduced, found and corrected. Over a series of releases it gives you a statistical level of confidence that the current release has a low enough number of defects to ship. I had about 1 day exposure to all this in a class - I'll see if I can dig up any references.

Ernest, which coverage tool you guys use?

Something I wrote myself which does bytecode instrumentation. It's OK, but we're thinking of moving to Clover, which looks much nicer.

Originally posted by Ernest Friedman-Hill:
Something I wrote myself which does bytecode instrumentation.

Haven't you ever written anything normal?

Thanks for the feedback.
Do you ever use metrics such as complexity measures or volume (optimal algorithm measures) and error estimation such as Halstead equations?

I've worked with the same small development team for quite a few years now, and we're confident in our own and each other's coding ability. I imagine that if we had a larger team, where we were bringing in people to whom we didn't have these ties, then we'd want to use complexity metrics and other code quality measures to make sure overall quality was being kept up.