Another question that is coming up is:
How can (or should) code metrics be presented to management ?
My view is that in all cases the metrics are something that can help make decisions around focus and prioritization. Management should be made aware of the metrics and what they mean to allow them to decide where to focus resources. If management is more levels away from the code then the Maintainability index can serve as a good, simple, metric.
Sometimes you may ship code that has low maintainability or very high complexity etc. and management would make this decision based on risk, time and resources and perhaps other factors. Metrics helps them make that decision with quantitative data.
Some possible options:
One option is to present the metrics in terms of risk and mitigation. For example:
- Risk: low maintainability in some module
- Mitigation: the module is reviewed.
- Risk: High cyclomatic complexity
- Mitigation: the module has a high number of test cases.
- Another option is to evaluate the metrics on legacy code. This could be to select some code that is known to have lots of issues and then run the metrics on the code to see if metrics would report any issues with the code. This could be a good way to show value to management in the metrics themselves and make them case for them as a future preventative measure.
- Yet another option is to present a trend over time. Unfortunately the tool doesn’t currently make this very easy but at each milestone of the project you can record the maintainability and other metrics for the modules. This could then be compared across time and used in future planning or to guide management in allocating time and resources to particular parts of the project that are trending badly.
I’d be very interested in hearing other approaches people have taken in presenting metrics or code analysis in general to management.