Positioning Code Metrics to Management

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:

  1. One option is to present the metrics in terms of risk and mitigation. For example:

    1. Risk: low maintainability in some module
    2. Mitigation: the module is reviewed.
    3. Risk: High cyclomatic complexity
    4. Mitigation: the module has a high number of test cases.
  2. 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.
  3. 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.

Comments (6)

Cancel reply

  1. Joe says:

    I’d keep metrics away from non-technical management.  The last thing anyone wants is for the metrics to be used as absolute targets as opposed to guidance.

  2. Brian Harry on Update #2 on Installation Questions. Steven St. Jean on VSTS Web Test Tidbit – Testing…

  3. conorm says:

    Joe raises a key point: the last thing anyone wants is for metrics to be used as absolute targets.  

    I totally agree with this but even non-technical management should appreciate if you are able to back up your business decisions with some data that could be based around these code metrics.

  4. Oded Gil says:

    I don’t use code matrices yet (vs2003) but, I use probability X impact to measure the risk.

    For example, if most of the code (let’s say 80%) is not readable. the probability to spent time to understand the code is 4 out of 5 and the impact is, let’s say, 2 out of 5 because after a few hours of line by line debugging the problem can be solved. The risk is 2X5=10

    Same way we do for performance, exception management, logging…

    This way I can present a nice graph showing the risk to the management, they can see the risk with the highest bar and make a decision to spent time and fix it.

    The idea was not mine, a consultant from Microsoft Israel thought about it first.

  5. [ Nacsa Sándor , 2009. január 19. – február 5.] Ez a Team System változat fejlett eszközrendszert kínál

Skip to main content