There is a question that haunts every software project, usually asked too late and answered too vaguely: Is this software actually good? Not good in the sense that the team believes in it, or that it passed a handful of tests before shipping - but measurably, verifiably, defensibly good. Good enough to meet a contract. Good enough to trust with a critical process. Good enough to stake your professional reputation on.
Most software organisations cannot answer that question with any precision. They rely on intuition, convention, and optimism. They ship, and they hope.
Software Metrics is the guide that replaces hope with method.
Written by Dr David Tuffley and grounded in IEEE Standard 1061 - the internationally recognised framework for software quality metrics methodology - this compact, authoritative book walks project managers, developers, quality assurance teams, and system maintainers through a rigorous, systematic approach to measuring software quality across the entire development lifecycle. Its premise is blunt: if you cannot measure it, you do not know it. And in software, not knowing costs money, reputation, and sometimes far more than that.
The book opens by dismantling the comfortable fiction that software quality is something you feel rather than calculate. Quality, it argues, is a ratio - the degree to which software possesses a desired combination of attributes - and those attributes must be clearly defined, hierarchically structured, and tied to quantitative targets before a single line of code is written. Without that foundation, every quality review is guesswork dressed in professional language.
From that foundation, the methodology unfolds across five interlocking steps. First, establish your quality requirements - not as vague aspirations, but as specific, quantified factors agreed upon by everyone with a stake in the outcome. Second, identify the metrics that will measure those factors, building a hierarchical framework that connects management-level concerns to the concrete, technical attributes that engineers can act on. Third, implement those metrics: collect the data, apply the tools, and run the measurement processes that will generate real numbers. Fourth, analyse what those numbers mean - interpret the results, identify anomalies, make predictions about where quality problems are brewing before they become expensive to fix. Fifth, validate: confirm that your predictive metrics are actually measuring what you believe they measure, using rigorous statistical criteria including correlation, tracking, consistency, predictability, and discriminative power.
That fifth step - validation - is where this book earns its authority. Most organisations that attempt metrics programmes never validate their metrics. They collect data and trust it. Tuffley shows precisely why that trust is unwarranted, and exactly how to establish it on solid statistical ground.
Throughout, the methodology remains flexible by design. The quality framework can accommodate any software system, any lifecycle model, any combination of product and process metrics. It can be expanded, adapted, and refined without abandoning its core logic.
The result is a guide that transforms software quality from a matter of opinion into a matter of evidence - giving managers the data to make defensible decisions, giving developers the targets to build toward, and giving organisations the discipline to deliver software that meets its quality commitments, provably, every time.
If you are responsible for the quality of software - or for the consequences when quality fails - this book belongs in your toolkit.
