Premature Optimization
On this page · 2 min read
Revised October 19, 2026. What changed
An optimization is premature when its cost is justified by an assumption you have not tested. The problem is not caring about performance early. It is committing to a complicated design before knowing which constraint matters.
Measure the constraint
Suppose checkout takes 900 ms at the 95th percentile. You can spend a week replacing a collection algorithm, but a trace might show that 700 ms is waiting for a remote service. First record the workload, percentile, throughput, error rate, and environment. Separate time spent executing from time spent waiting.
A monolith is not automatically faster in every useful sense, and a microservice is not automatically scalable. Network hops, serialization, queueing, deployment independence, and team ownership all affect the choice. Choose a boundary for a concrete requirement, then measure its cost.
Make the experiment smaller than the commitment
- State the target: for example, checkout p95 below 400 ms at the expected peak load.
- Capture a representative baseline and identify a dominant contributor.
- Change one thing and rerun the same workload, including warm-up and repeated trials.
- Compare memory, correctness, tail latency, and operational cost as well as the headline speed.
- Keep the simpler implementation if the improvement is immaterial.
When early work is necessary
Hard memory limits, safety deadlines, and an unavoidable data volume can rule out a design before a full implementation exists. Estimate those constraints early. A capacity model or small prototype can answer the architectural question without turning every line of code into a performance project.
Keep the benchmark input and command with the change. A result without its workload is difficult to reproduce and easy to overgeneralize. The same discipline applies when deciding whether an agent improvement deserves release.