My argument is not that metrics are good or bad (they're just data, after all) but that they are gross simplification of the thing that they are measuring.
The question is always; does the metric provide useful information? I had to replace the fuel tank on my car recently. Knowing its volume was useful information but knowing its colour wasn't. (On the other hand; if I rode a motorbike then maybe the colour would be important, too.)
In the case of metrics that are compiled from the code; I think that a manager who has no interest in the code implementation details (because it's not something that they need to know) equally should have no interest in a metric generated from that code - whether it be line count, crappiness, complexity or whatever.
I said in my original statement that they are a blunt tool of interest only to the actual developer. I think that the 'crap' metric illustrates that. The 'crap' metric is a meta-metric in that it takes two metrics (each of which measured independent properties of the code) and combined then to produce a third figure. In doing so knowledge, of what the actual problem in the code was that was being flagged, was lost.
I have applied it to some code I wrote recently and it highlighted a number of methods that potentially warranted further attention. What it did not indicate is why those methods were 'crap'. To do that I needed to look at the two figures that were combined to created that metric. Until then I did not know if the code was too complex or too untested (or both). Fortunately, the tool you provided (for the eclipse IDE) makes that information readily available but the fact is that the original metric is just a flag that carries no information than to say "look here".
I therefore stand by my assertion that code metrics, that are mechanically generated from the code, are only of interest to the code developer and do not provide any useful information to a project manager.
Flat View: This topic has 50 replies
on 51 pages
[
«
|
272829303132333435
|
»
]
Previous Topic
