A threshold that breaks the build

Measuring code complexity is fine, but a number that only shows up in a report nobody opens changes nothing. Technical debt doesn’t arrive all at once: it slips in one function at a time, each a little worse than the last, none bad enough to stop anyone. By the time it «feels tangled», it’s already late.

The way to halt that drift is to set a limit the process enforces on its own.

The build as gatekeeper

The idea is simple: you set a per-function complexity threshold and measure it on every change inside continuous integration. If a function crosses it, the build fails — just as it fails on a broken test or a type error. It isn’t a warning you can ignore; it’s a closed door.

A warning piles up. A broken build gets dealt with. The difference between the two is whether the rule actually holds.

Calibrate, don’t strangle

The right threshold isn’t the lowest possible. Too strict and the team disables it within a week; too high and it protects nothing. It’s best to start it above what you already have —so you don’t break the build on day one— and lower it as the existing code gets cleaned up.

It also needs an honest escape hatch: an explicit, visible way to say «this function exceeds the threshold on purpose, and here’s why». The documented exception is information; the silent exception is the beginning of the end of the rule.

Framed that way, the threshold stops being bureaucracy and becomes what it should be: a team agreement about how much complexity it’s willing to carry, defended by a machine that never tires and makes no exceptions when things get rushed.