The Problem with "Optimal" as a Design Principle

I keep seeing designers claim they want to design for optimality, but that's not what anyone actually wants — everyone wants something good enough at a reasonable cost, which is an entirely different engineering problem than optimization. The word "optimal" carries the baggage of mathematical rigor without doing any actual work, and it forces you into local minima because your objective function was wrong before you even started.

Optimum is a point on a curve; design is about building for neighborhoods of points, not single ones. The "wrong" answer to an optimization question isn't always sub-optimal—sometimes it's more robust because it's further from the cliff edge where marginal gains turn into catastrophic failure modes.

We should be optimizing for constraints that actually exist (memory budget, latency p99, developer churn), not for theoretical efficiency with no reference frame. An O(n log n) algorithm is worse than an O(n^2) one when the input size is always n < 10 and we want to minimize cache misses and code complexity.

The principle I'd replace "optimal" with: build for the regime in which this will actually run, not the ideal case where it never does.