BuildMetrics

Interesting metrics:

• Quality?
• Near to release?

Adding code coverage to every build

• % of code
• % of branches
• watch the trend
• trend should grow
• Cobertura shows this

When transitioning to TDD, watch coverage

List of interesting metrics (dynamic or static properites of the product)

• line coverage
• branch coverage
• pmd
• findbugs
• checkstyle
• jdepend
• complexity metrics (NCSS, Callistic)

* links between metrics highlighted
* defects added
* defects corrected
* densisty of defects for project

Metrics from CI system:

• time for build
• time for test
• commit frequency
• pairing matrix
• time for completion for user story

Bumble

• identifies which unit test breaks the build the most

What is the real use of the metrics?

Use of metrics will affect behaviour of developers.

Experience of setting up Sonar. Often fails, developers start to ignore

Much easier if you start with new code, and don't let new defects in. Keep clean. Harder to apply to legacy code, because the number of warnings if often overwhelming.

Ivan: story of project that used static analysis tools from the start, but the code was a complete mess. This was probably as a direct result of the tools used for measurement

Interesting to correllate bugs to programmer or pair.

Book "Measuring and Managing Performance in Organisations": if you manage people by a metric, they will responding by gaming the system. That doesn't necessarily mean that you shouldn't use the metrics

Need to carefully choose which metrics to measure, and interpret intelligent conclusions from metrics. Can necessarily do this automatically.

Learning how to use the information presented. Collate data. What will the team do with the information? Will external groups monitor the metrics?

BI (Business Intelligence) - managers see similarities with code metrics. Can be helpful to distill code metrics to simplifed metrics based on threasholds. eg. very maintainable