Jack was of the opinion that:
the more one spends time tracking metrics, the less time there is for development
While I have some sympathy for this point of view having worked for larger organizations in the past, I have come to realize that you do need some type of metric that is understandable to the rest of the organization. All the other departments in your organization have an overriding single number that describes how they are doing, why not software development?
As I mentioned in my No More Iterations post, throughput is my metric of choice. The cost of collecting this metric is so low that it doesn't matter.
Now I have been asked to provide all sorts of low level metrics in the past not knowing how they were going to be used. I was not inclined to cooperate in those cases since the time required to collect them was never going to be offset by any value coming back to my teams. And this is most likely what Jack is protesting.
I like being proactive and providing a metric I think is useful, rather than waiting for someone who doesn't really understand software development ask me to have my teams track actual effort against estimated effort in units of 0.1 hours (really I have been asked to provide this!).