ImpactGate Puts a Number on How Much a Change Wears Code Down
OfficeFloor has published ImpactGate, a tool that measures and gates the structural decay a change introduces.
Repository material published 2026-09-16 GMT documents the release. OfficeFloor ImpactGate repository
The OfficeFloor GitHub organization describes the project as "Code review via the change impact measure" and lists Python as the repository language. OfficeFloor organization page
Distribution is through Python packaging. The command installs via pip install impact-gate. Project documentation is hosted at https://impactgate.officefloor.net.
How it runs
Execution covers three integration points. ImpactGate runs as a standalone CLI, a command-line tool run by hand, as a git pre-commit hook, an automatic check before a commit is saved, or as a plugin in GitHub, GitLab, and Jenkins CI, the automated checks that run before merge. That placement puts the check both in the local edit loop and in the merge pipeline.
How the score works
Scoring is differential against a base branch, main by default. ImpactGate computes impact = files_changed * sum of max(WMC_other, 1) * CC * delta-lines over changed functions. The files_changed term scales the result by breadth of touch. The summation runs over changed functions, weighting cyclomatic complexity (CC), the count of decision paths in a function, and delta-lines, the lines added or changed, by class-level weight (WMC_other, floored at 1).
Why it matters for review
The broader context here is familiar to anyone who has maintained a large codebase. Lint rules catch formatting and narrow defects. Structural decay is different, like wear that builds up even when each trip seems fine. It accumulates when small, locally reasonable edits increase coupling, branching, and cross-file surface area. A per-change measure makes that cost visible at review time rather than during later refactoring.
In my view, the formula choice is pragmatic. Multiplying by files_changed penalizes scattered changes. Weighting by CC and WMC_other penalizes edits in already complex functions and classes. Using delta-lines keeps the focus on what the current diff adds, not on inherited complexity. Developers get a number tied to their own edit, not a repository-wide grade.
Looking at what this means for teams running trunk-based or short-lived branch workflows, where code merges fast to a shared branch, local and CI enforcement matter more than the metric alone. A pre-commit hook gives fast feedback before push. CI plugins for GitHub, GitLab, and Jenkins move the same calculation into merge gating, where policy can be enforced uniformly. The CLI covers ad hoc use, bisect work, and custom automation.
Worth flagging, any single scalar will be gamed or misread if applied without judgment. High impact does not always mean bad design. A cross-cutting rename or a deliberate extraction can touch many files and lines while reducing future complexity. Low impact does not guarantee clean abstraction. The value lies in forcing an explicit conversation at the point of change, with a repeatable quantity attached.
That review-time focus is where long-term optimism is warranted. Tools that quantify decay rarely eliminate it. They change defaults. When the cost of complexity is surfaced in the pull request, smaller, better-scoped changes become easier to defend. Over many merges, that bias compounds.
