At the two extremes both have their points, the pro measurement group quotes that building software is a business hence needs visibility and measurements. They would tell you that start by measuring with whatever you can measure and eventually we would learn and will be refine it and would help us in making better decisions in future.
They would also tell you that measurements are used, only to help. track the status, measure productivity and not intended to point fingers or fire people.
While on the other hand, geeks stay at another end and say, software development is almost writing poetry hence cannot be measured quantitatively but should be measured qualitatively. They would make mockery of the measurements like lines of code, by saying that its the biggest joke, they would tell you that this measurement discourages efficient code writing. The more code write doesn't mean that you are writing it well.
There was this classic case in which, I came across where people were measured on the number of tester approved releases made, this measurement had paved the way for a culture where developers and testers acted in concert to make releases frequently as possible, at times even a dozen releases within a fortnight, at times even the smallest bug fix is fixed and sent out as a release.
While the two parties stay at two extremes, we need to keep in mind that we need to have some indicators while rationally picking the measurements and most importantly know to interpret it without blindly using it.
Anyone who wants to design a measurement system should remember that unless done carefully it leads to sub optimization and remember the golden saying
" What you measure is what you get " if you measure lines you get more lines, if you measure bugs you get more bugs, if you measure the overall contribution to the success of the project you get more people contributing to the over all success. Just some food for thought.
Sent from my BlackBerry® wireless device