GqmSoftwareComplexityAssessment
title: GQM Software Complexity Assessment radar_quadrant: Techniques radar_ring: Assess radar_position: inner
Most complexity discussions in code review devolve into opinion — "this feels over-engineered" versus "this is fine" — with no shared way to settle the disagreement. This technique replaces the argument with a structured scoring exercise, borrowed from the Goal-Question-Metric framework used in academic software measurement, and adapted into a five-step process anyone can run during an architecture review, a pull request evaluation, or a pre-refactor baseline.
The process runs in five stages. First, the reviewer frames the assessment: what part of the system is in scope, and what future change scenario is it being evaluated against (e.g. "how hard would it be to add a new payment provider"). Second, they collect evidence in a fixed priority order — contracts and interfaces first, then source structure, then version history, then runtime data. Third, they measure a standard catalog of design principles against that evidence: single responsibility, deep modules (a lot of functionality behind a simple interface), single knowledge owner, clear design boundaries, and whether the system can represent invalid states. Fourth, each principle gets a score from 0 to 3, paired with a separate confidence rating, because a low-confidence score is a very different signal than a well-evidenced one. Fifth, the reviewer traces low scores back to root causes and ranks findings by how much of the system they actually affect.
The method is explicit that a score without cited evidence is not a valid score, and that static metrics (cyclomatic complexity, line counts) are treated as smoke rather than proof — a warning to look closer, not a verdict on their own. It also discourages comparing scores across unrelated projects, since the scale is only meaningful relative to a specific codebase's own change scenarios.
This is placed in Assess, inner position. It requires no tooling — the entire technique is a documented checklist a reviewer can run by hand — which makes the barrier to a first trial very low: the only gate to Trial is actually running it once against a real change scenario and finding it produced a more defensible outcome than an unstructured review. Inner position reflects that low barrier, not proven value; the framework itself is unverified beyond the single gist documenting it, and there is no first-person track record yet of it changing a real review decision.
