Why Don’t We Design Slower Algorithms?

Suppose two algorithms return the same correct answer. One takes a second; the other takes a minute. Unless the extra minute buys us something, there is little reason to prefer it. Much of algorithm design starts from some version of this comparison. What interests me is the phrase “the same answer”: it can hide a great deal about what we wanted the computation to accomplish.

1. The assumptions behind speed

For a fixed computational problem $P$, we can compare algorithms that solve it correctly by the resources they consume. If running time is the resource we care about, and $T_A(n)$ is the time algorithm $A$ takes on inputs of size $n$, the objective has the familiar form

$$\min_{A:\,A\text{ solves }P} T_A(n).$$

This comparison treats the outputs of correct algorithms as equally valuable and time as a cost. Under those assumptions, faster is better. The difficulty begins when the output does not capture everything that matters. A proof may be correct regardless of how it was obtained, but the person who receives it may understand very little of it.

2. A proof delivered, a proof understood

We already accept extra computation when it serves another objective. Password-hashing schemes such as Argon2 deliberately make guessing expensive in both time and memory. In machine learning, we may spend more computation for better robustness; in a distributed system, additional verification may improve reliability. These are reasons to judge an algorithm by more than its running time, not reasons to value slowness for its own sake.

Consider two AI systems that can prove the same theorem. One returns a complete proof in a second. The other spends ten minutes asking questions, offering hints, and helping the user work through the argument. If all we need is the proof, the first system has done the job. If we want to learn the mathematics, the second may be more useful, provided its guidance actually helps us understand.

The ten minutes alone tell us nothing. We could spend them staring at a loading screen and learn nothing at all; we might also understand a well-written proof without needing a guided conversation. The relevant difference is what happens to the learner. Once that change becomes part of the task, comparing only the time taken to produce a proof leaves out a large part of the work.

3. When the process is part of the goal

A symphony is an obvious case where finishing sooner is not the point. Reading War and Peace offers another: a one-second summary might convey how the story ends, but it would not give us the experience of reading it. In both cases, reaching the final state is an inadequate description of the activity. Something we value happens along the way.

It may help to distinguish instrumental computation, where the process is chiefly a means to an end, from experiential computation, where participating in the process is part of what we want. These are working descriptions, not established categories in complexity theory. The same system can serve either purpose: a proof assistant might help a researcher finish a calculation, or help a student learn why it works. The appropriate objective depends on which task we have given it.

4. What the objective leaves out

Turning an $O(n)$ algorithm into an $O(n^2)$ algorithm is easy enough; unnecessary work will do it. The harder question is whether some of the time we remove in making a system faster was doing useful work for its user. To make that distinction explicit, start with an objective that counts only time:

$$\min_A T(A).$$

We could instead account for both the result and what happens during the computation. A schematic objective would be

$$\max_A \left[V_{\mathrm{out}}(A) + \lambda V_{\mathrm{process}}(A) - \mu T(A)\right].$$

Here $V_{\mathrm{out}}$ is the value of the result, $V_{\mathrm{process}}$ is the value produced through understanding, participation, or other aspects of the process, and $T(A)$ is the time cost. The weights $\lambda$ and $\mu$ express how those considerations enter the objective. This is a way to state the problem, not a finished theory: we still need to say whose understanding matters, how to assess it, and which changes can reasonably be attributed to the system.

An algorithm that takes longer could do better under this objective, but only if the additional time contributes enough value to justify its cost. A delay by itself earns nothing. For a learning system, the useful comparison would include what the user can explain or do afterwards, rather than treating time spent as evidence of learning.

5. The complexity of understanding

This raises a question about the resources needed to understand an answer, as distinct from those needed to compute it. For an observer with limited cognitive resources and specified prior knowledge, what information, interaction, and time are needed to reach a particular level of understanding? A lower-bound claim would need a model of that observer and a criterion for understanding. Without those, talk of a minimum number of hints or cognitive updates remains a research question, not a result.

The fastest way to find a solution may not be the fastest way to help someone understand it. That is the distinction I would like to formalize. Speed still matters, including in teaching: needless difficulty and waiting waste time that could be used elsewhere. But before optimizing a process away, we need to know whether it was merely taking us to an answer or helping us become able to reach one ourselves.