Traditional Software Production Metrics

Traditional methods of controlling software production systems have focused on the use of effort-based metrics. The old bell wether has been the line of code (LOC). Almost everyone in the software business will tell you that lines of code is a useless metric. The problem with LOC is that it is an effort-based metric. It is meaningless for measuring the delivery of software value, the output from the system. However, for want of a better metric, lines of code remained popular for a long time.

Another favorite metric is the level-of-effort estimate, generally an estimate in man-hours for the development of a certain piece of requested functionality. The effort expended in hours is then compared with the estimate and adjusted periodically.

Traditional software metrics relate to the Operating Expense (OE) metric. Traditional software metrics are compatible and perhaps heavily influenced by traditional cost accounting methods. They are focused on cost. Focusing on managing OE is suboptimal in achieving the system goal of more profit now and in the future, with a healthy ROI. It is more important to focus on Throughput and Inventory. Hence, traditional metrics do not meet the criteria for relevance.

Nor do they meet the criteria for simplicity. The business of software production is nonlinear. As software production is a complex system with feedback loops, it exhibits nonlinear behavior, that is, the effort expended in the system to produce lines of working code is not proportional to the quantity or quality of the output from the system. Hence, tracking effort-based metrics requires the translation through an unknown nonlinear equation in order to communicate client valued functionality.

Effort-based metrics are not always self-generating. Every developer who has filled in a time sheet can tell you that the time sheet did not self-generate.

Effort-based metrics are not very useful as predictive indicators because of the nonlinear nature of software development and inaccuracy in estimation. The estimate is unlikely to represent the final outcome. Hence, the actual results must be gathered historically. When a developer fills a time sheet, it is an historical record rather than a predictive estimate. Hence, time sheets and effort recoding are lagging indicators.

Traditional software development metrics of lines of code written or time expended do not meet any of the ideal characteristics for system control metrics.