Is measuring software project metrics popular in todays industry?

Question

I encountered a developer who wanted some outside advice on their teams project. I found out they're developing a huge software suite for the companies executives, project manager and developers that can calculate metrics automatically and graph them per iteration.

As a student from a computer science background I know very little on metrics and their importance, but my questions are:

1. Do most companies have some way, doesn't have to be an elegant program, to measure meaningful metrics?
2. Which metrics, single or combined, help you narrow down your projects scope and estimates?
3. As a person who analyzes metrics, how often do you base decisions off of them? IE. Tests failed per week is increasing drastically?
4. Do you feel that the introduction of studying metrics has helped you understand the project better?

Not sure why but the developers project intrigued me and I must know more. If y

Answer 1

Some books on metrics that your college library probably has include Software Metrics and Metrics and Models in Software Quality Engineering. Those 2 should give you a starting place. In the industrial world, very few companies have any sort of metric measurement program at all.

Do most companies have some way, doesn't have to be an elegant program, to measure meaningful metrics?

Visual Studio includes some code analysis tools that can get you started. Most companies don't even have something to measure the worst metric possible: lines of code. "Just get it done" appears to be the overwhelming driving force in the industry, and concerns of maintainability are given very short attention to managers' concerns of "will I get my bonus this year?" and "will this be done in the time I promised?" Even with products that carry over from year to year with incremental changes, those 2 concerns dwarfed the developers concerns of maintainability and bug detection/prevention.

Which metrics, single or combined, help you narrow down your projects scope and estimates?

I find that cyclomatic complexity and coupling are strong indicators of how buggy or how hard to maintain the code will be. If the cyclomatic complexity is around 20, I find that it will be almost impossible to test (as it will have up to 2^20 paths through the code) and should be decomposed into smaller pieces. You cannot eliminate complexity, but you can slice it up into more manageable chunks.

If you are looking for estimation, you probably want to investigate function points.

Code coverage % is drastically lowering each iteration, do you alert your developers of the issue

I find that most managers care about number of check-ins and number of bugs getting fixed. My current manager is opposed to unit testing (he thinks it is a waste of time) and my previous manager felt that time spent on unit tests was time that should have been spent writing it in the first place.

The canonical argument used by developers is that if you measure something, that's only what you will get. This argument comes from the idea that the only metric is lines of code.

Answer 2

I was at a talk about software metrics where the speaker made some, IMHO, insightful points. Having little experience with these things myself, I was still intrigues and inspired, but I cannot say if it's wrong or right.

The main ideas were:

• No singular metric is useful in it's own right.
• Setting an absolute target (i.e. XX % code coverage) is not meaningful.
• A metric without history is useful.

So, to solve this:

• Show several metrics, such as:
  • # of lines total / changed
  • # of commits
  • % code coverage
  • # of tests
  • cyclomatic complexity
  • file/package/... dependency
  • ...
• Show data from QA/CI:
  
  • # of bugs/enhancement/changes (I personally think this categorization is important)
  • # total/added/fixed
• Show these metrics on graphs that show trends over time

This way, when tickets are fixed rapidly, one can see if the code quality goes down. Also, when not much seems to be happening with the bug database, code quality might go up, as refactorings are being done.

Summing it up: It's this type of dynamic behaviour that's important and what gives you information rather than raw data (which would be the value of a single metric).

I'm planning to put some graphs according to this scheme on a widescreen TV next to our CI connected lava lamps. ;)