The purpose of a software metric is to make a complex thing simple so that it can be evaluated quickly. It's a compression process that reduces a piece of code to a single integer. In the same way that if a picture was reduced to a single pixel, all detail is lost in the process.
The average picture, reduced to a single pixel, would produce a pixel that is grey with a brightness of about 18%. If you take a picture and process it in that way and your result is slightly green with a brightness of 25% then what does that tell you about the quality of the original picture? Nothing.
If I run a metric against my day's work and the result is "17" and a co-worker's day's work can be summed up as "12", what does that tell anyone about the work that we've done today? How good is our code? How much of it is there? How complex was the task being coded? How old is the code? Etc., etc. All that information is not only lost but it was never embodied in the code in the first place.
The fact is that the metric - being a mechanical derivative of the code - is of no real value except to the individual developer and then only as a blunt pointer to potentially problematic code.
Manager are rarely interested in implementation details, so there little or no reason for them to be interested in a single numbers derivated from those details. Fortunately, my experience is exactly that.
Vince.
Flat View: This topic has 50 replies
on 51 pages
[
«
|
212223242526272829
|
»
]
Previous Topic
