The Disconnected Ruler

Software metrics research has produced thousands of papers measuring code complexity, defect density, test coverage, coupling, cohesion. The measurements are precise. The studies are rigorous. And nearly none of them are used to make software engineering decisions.

Briand (arXiv:2603.16012) diagnoses the disconnect: software metrics research developed without engaging with metrology — the science of measurement itself. The field measures properties of software without establishing what those measurements mean for the decisions they’re supposed to inform. A cyclomatic complexity of 15 is precisely computed, but what decision should it trigger? At what threshold? For whom? Under what conditions?

Metrology requires a chain from the measured quantity to the decision it supports. In physical engineering, this chain is explicit: a material’s tensile strength is measured in units that connect directly to structural load calculations, which connect to safety factors, which connect to pass/fail decisions. Each link is validated. The measurement serves the decision; the decision justifies the measurement.

In software metrics, the chain is broken. Measurements exist without decisions. Decisions exist without validated thresholds. The research asks “can we measure this?” rather than “does measuring this help someone decide something?” The result: a field full of precise instruments calibrated to nothing.

The structural problem is that measurement and decision developed independently. Researchers optimized measurements for statistical significance — can we distinguish high-complexity modules from low-complexity ones? Practitioners needed actionable thresholds — should I refactor this module? The gap between “statistically distinguishable” and “actionably different” was never bridged because the two communities optimized for different things. The ruler is accurate. It is also disconnected from everything it could measure for.