When do you accept a hidden-quadratic call inside a loop instead of paying for the rewrite?

## Why this is a judgement call at all Every hidden-cost finding in a review arrives with an implied verdict: it is quadratic, therefore fix it. That reflex is mostly right and occasionally expensive. Big-O is an **upper bound on growth**, not a statement about the wall-clock cost of the input you actually have, and a lead's job is to convert a growth fact into a decision under real constraints: a latency budget, a batch window, a team's maintenance capacity, and a backlog with other things in it. ## The five questions that decide it **1. Is the input bounded, and by what?** There is a large difference between "today it is about 200 items" and "validation rejects more than 200 items". The first is an observation that will expire; the second is a contract that a test can defend. Ask who can make the number grow — a customer uploading a bigger file, a new caller reusing this path in bulk, a merger doubling the account list. If the answer is anyone outside your team, treat the input as unbounded. **2. What is the measured cost now and at ten times?** Not the asymptote, the number. A quadratic pass over a few hundred items is microseconds. The ten-times run is the one that matters, because that is where a quadratic separates from a linear alternative by a factor of a hundred. If ten times today still fits inside the budget with room, the growth curve is not yet your problem. **3. Where does the code sit?** A synchronous request path shares its budget with everything else in the request and fails loudly and publicly. An offline job with a wide window absorbs a lot. The same line deserves different verdicts in the two places, and saying so is what distinguishes judgement from rule-following. **4. What does the fix cost the team?** Sometimes the fix is *smaller* code — hoisting a loop-invariant call, replacing a scan with a set lookup — and then there is no trade to discuss; take it. The genuine dilemma appears when the fix adds an auxiliary structure that must be kept consistent with the primary data: a second index that can now go stale, an incremental aggregate with its own invalidation rules. That is permanent complexity paid for a speed you may not need, and the correctness risk of a de-synchronised index can exceed the cost of the slow path. **5. What is the blast radius if you are wrong?** A quadratic that gets slow is a bad afternoon. A quadratic in an unbounded path that becomes a resource exhaustion vector under attacker-controlled input is an incident. Anything whose size an untrusted caller controls stops being a performance conversation. ## What acceptance must include Accepting a known quadratic is defensible; accepting it *silently* is not, because it is not the decision that fails, it is the decision's invisibility a year later. Attach three things: - **An enforced bound.** Turn the assumption into validation or an assertion, so exceeding it fails as a clear error rather than as a mysterious timeout. - **A test at the bound.** A check that runs the path at the assumed maximum and fails when the maximum rises. This is what converts "fine for now" into something the build maintains for you. - **A recorded reason.** Not "this is O(n^2)" — the reader can see that — but the *bound and the budget*: what input size was assumed, what it measured, and what changes the answer. ## Making it a habit rather than a debate At team scale, the goal is fewer instances reaching review, not sharper arguments in review. Practical levers: a review prompt that asks what each call inside a loop costs and whether its input can grow; a performance test at a multiple of production volume for the paths that matter, so regressions surface as a failing build rather than a page; and a short shared vocabulary for the recurring shapes — a membership scan inside a loop, a superlinear call whose input never changes, a value materialised only to be read — so people recognise them by sight. ## The failure modes at both ends The over-eager end is complexity theatre: blocking a change over a quadratic on a hard-capped input, buying a fragile index with no measurement behind it, and spending review capital that the genuinely unbounded path next week now cannot get. The permissive end is the one that produces incidents: "it has always been fine" repeated until the input size changes owner. A defensible position names the bound, cites a measurement, and leaves behind something that will fail loudly when the assumption stops being true.