Metrics [351]

This mornings class for software engineering was on metrics in software development.

There are various things that can be measured with in project. Metric are useful but can be difficult to implement. For example just measuring lines of code [LOC]can be tricky because one developer may write compact code with the same functionality that another write in a much more convoluted way (ergo using more LOC). Different programing languages require different amounts of LOC for the same functionality. Then there is different measures of LOC i.e., With or without blank lines, with or without comments, etc etc. All measures have have there various nuances which you have to be careful of and must be aware of when using them.



Care should should also be take on how this information is used; who has access to this information, what it is used for, who the information will affect in the future.
Data from the metric can be useful if shared within a team. Analyzed results, indicating the health of the project would be good for management, but individual performance would not. Metrics which will have an effect individuals rather that something of a larger scale (i.e., a project) can not be reliably used if the individual concerned is able to affect the results of the metric concerned. For example just using LOC as a measure for performance appraisal, may lead a programmer to write extra unnecessary code.
This would can lead to skewing of the result of the metrics; reducing the metrics usefulness.

The wider implication of this can be quite large. I have read somewhere (but unfortunately can not find the reference) proposing that Enron changed from a company, which transparency, honesty and accountability were core values, to one where corruption and deceiving practices were the norm (which lead to its scandalous down fall)because of the practice of firing of the lowest performing team members based on flawed metrics. (This policy was introduces by the CEO create competition between team members (out of fear of being the bottom performing member and then getting fired) which would lead to increased productivity. This performance was based on flawed metrics which could be skewed. This is an extreme example but it shows the importance of getting it right.

Metrics are often more useful when measure against another measure i.e., errors found per LOC or LOC per person month.

There are many different metrics that can be used not just LOC


There is an importance in storing metrics data for later use (there is no point in making the measurements if you are not going to use them later) A project may take a year or more, so data will need to be stored in a useful manner for years to come.


My own thoughts on what metrics implies:

The question is then what to do with the data!?
It can be used to provide feedback to improve the weighting factors used in estimating the size of projects. For example if you used (say) 6.5 function points is equivalent to one person month. But found from your metrics that 6.2 was a better weighting factor for estimation. It could also be used in a similar way to mile stones to gauge progress of a project.
Then there is using data in the context of a Deming (or PDCA, or Shewhart) cycle (http://en.wikipedia.org/wiki/PDCA )to measure performance, isolate a possible weak area, plan ways to improve, do something to the effect of the plan and measure again (and the cycle continues) PDCA cycles work best is there is some hard data to act upon (other wise you may be making things worse when they don't need changing because you acted on some subjective (non)data. )

Deming http://en.wikipedia.org/wiki/W._Edwards_Deming is a personal hero of mine so I had to put in a reference to him.