A colleague spent a week optimising a function and the endpoint is 2% faster. What went wrong in the approach?

What is being tested

Whether you understand that optimisation payoff is bounded by the share of total time the component occupies, and that measuring first is not optional.

The arithmetic

Amdahl's law: if a component is fraction p of total time and you speed it up by factor s, overall improvement is bounded by 1 / ((1−p) + p/s).

A 2% overall improvement means the component was a small fraction of the total. Even making it infinitely fast would have delivered only slightly more than 2%. The ceiling was known before the week started — if anyone had measured.

What went wrong

They did not profile first. Intuition about where time goes is reliably wrong. The function probably looked inefficient — a nested loop, an obviously naive algorithm — and looking inefficient is uncorrelated with mattering.

The habit that prevents this: look for the widest frame in a flame graph, not the ugliest code.

The method that should have been followed

1. State the objective. "p99 under 300 ms" or "40% less compute cost". Without a target, optimisation has no stopping condition and consumes unbounded time.
2. Profile under production-like load and data. Development profiles find development problems.
3. Optimise the dominant term, and estimate the ceiling before starting. Five minutes of arithmetic would have shown the week was not worth spending.
4. Measure again, confirming the improvement is real and nothing regressed. Optimisations frequently move cost rather than removing it.
5. Stop when the objective is met. Further optimisation costs complexity and readability for no benefit.

The hierarchy that produces real wins

1. Do it less often — caching, memoisation, incremental processing instead of full recomputation.
2. Do less work — a better algorithm, fewer rows, a smaller payload.
3. Do it in parallel.
4. Do it faster — micro-optimisation. Last, smallest, and where the most effort usually goes.

Most significant improvements come from the first two, and they are architectural rather than local. A week spent removing an N+1 pattern or adding a cache would very likely have delivered an order of magnitude more than a week spent on a function.

What a strong answer adds

That the work may still have been worth something if it improved clarity or removed a future risk — but it should have been framed as such, not as performance work. And that the failure is a process failure rather than a personal one: if profiling is not a required step before optimisation work is scheduled, this outcome recurs.