↓Skip to main content

The Multiplication Trap: Why Feedback Beats Perfection

·7 mins

There’s a formula I keep coming back to:

Success = Quality × Quantity × Continuity

I like it because it’s not a metaphor, it’s an actual multiplication. And multiplication has a brutal property: if any factor is zero, the result is zero. It doesn’t matter how high the other values are.

This has a direct consequence for how teams (and individuals) should think about their work.

Evidence: the pottery class #

Before diving into the argument, it’s worth noting that the relationship between quantity and quality has been observed well outside software. There’s a well-known parable (popularized in the book Art and Fear by Bayles and Orland) about a ceramics teacher who divides a class into two groups: one graded purely on the number of pots produced, the other on the quality of a single perfect pot. At the end of the semester, all the best pots came from the quantity group. By making hundreds of pots, they learned what the quality group only theorized about.

The original story was actually about a photography class taught by Jerry Uelsmann at the University of Florida; the authors changed it to ceramics because they’d referenced photography too much elsewhere in the book. Regardless of the medium, the observation holds: iteration produces learning, and learning produces quality. You can’t think your way to expertise that requires doing.

This maps directly onto the formula. The quality group had high aspirations (Quality ≈ 1) but Quantity ≈ 0. The product of their semester was accordingly modest.

The discussion that produces nothing #

You’ve seen this. A problem is identified. A meeting is scheduled. People share strong opinions about the right approach. An hour later, everyone leaves with a richer appreciation of the problem space and zero new information about whether any solution actually works.

Discussions feel productive. They’re effortful, they involve smart people, and they create the sensation of progress. But a discussion, however good, has Quantity = 0. No output, no feedback, no data. Multiply that by any Quality score you want: the result doesn’t change.

Patrick Dubroy makes a related point in his recent post Fast is better than slow: the reason fast programmers are better isn’t raw speed, it’s that they get data sooner. Every cycle of build-and-observe teaches you something a discussion cannot. Waiting, whether out of perfectionism or habit, delays that learning without making it cheaper.

The smoothness argument #

Marcus Raitner’s Slow is smooth, smooth is fast comes at this from a different angle, and at first it seems to contradict Dubroy. Raitner argues for sustainable pace over frantic output: Amundsen’s steady 15 miles a day beating Scott’s irregular bursts. The point isn’t to slow down, it’s to avoid the false speed of haste that generates errors, rework, and eventually, collapse.

These two positions aren’t in conflict. They operate at different levels:

  • Dubroy is talking about iteration speed: don’t delay starting, don’t polish before shipping, get the PR out.
  • Raitner is talking about system pace: don’t burn out, don’t confuse activity with progress, keep a rhythm you can sustain indefinitely.

In terms of the formula: Dubroy addresses Quantity, Raitner addresses Continuity. Both matter. You can’t multiply them away.

Quality is not what you think it is #

The trap most teams fall into is treating Quality as the primary variable and trying to maximize it before touching the others. Ship only when it’s ready. Discuss until the approach is sound. Wait until you’re confident.

But Quality in isolation is not success, it’s inventory. Code that isn’t running, features that aren’t used, decisions that aren’t tested against reality. And there’s a subtler problem: your Quality estimate before shipping is based on incomplete information. The feedback you get after shipping is the data that tells you whether your quality assessment was even correct.

Oliver Burkeman’s 70% rule, cited by Dubroy, addresses this directly: if you’re 70% satisfied, ship it. Not because quality doesn’t matter, but because the gap between 70% and 100% is largely speculation about what “done” means, and that speculation is cheaper to resolve with data than with further discussion.

The AI trap: when cheap iterations become noise #

There’s a new version of this problem worth naming. AI tools (code assistants, generative prototyping, vibe coding) have collapsed the cost of iteration dramatically. A feature that used to take days can be roughed out in hours. This should, in principle, be a pure win for the formula: Quantity goes up, learning accelerates, Quality follows.

But cheap iterations introduce their own failure mode: the “just one more” trap. When generating a variation costs almost nothing, the temptation is to keep going, refining, tweaking, trying a slightly different approach, without ever committing to an output or exposing it to real feedback. AI can loop indefinitely without producing any real-world signal.

The Quantity in these cases is high. But if none of the iterations are ever shipped or tested against reality, Continuity of learning is broken. You’re running in place, not moving forward. This is a new instance of what Melissa Perri calls the Build Trap in her book Escaping the Build Trap: organizations that measure success by outputs rather than outcomes, shipping features to feel productive rather than to solve actual problems. Worth noting: Perri made that argument in 2018, well before the current rise of LLMs and agentic AI. The trap is not new, and it was never really about tooling. But AI lowers the cost of output so dramatically that an old trap becomes even easier to fall into.

This is precisely where Amundsen’s discipline becomes more relevant, not less. He didn’t stop at 14 miles because conditions were bad. He stopped at 15 because that was the plan, and plans exist to prevent both under- and over-exertion. In an AI-assisted workflow, the equivalent is deciding in advance: what question are we trying to answer with this iteration? When do we stop and look at results? What does “done enough to test” mean?

Cheap iterations are a gift. But they need a frame around them, or they become a different kind of procrastination, one that feels productive because code is being generated, but produces no more feedback than the pottery group that never touched clay.

What this means in practice #

The formula suggests a specific priority ordering when you can’t optimize all three factors simultaneously:

  1. Protect Continuity first. Burning out, creating unsustainable processes, or building a culture of heroics sets Continuity toward zero and eventually zeroes out everything else. This is Raitner’s point.

  2. Maximize Quantity second. More iterations, more feedback cycles, more small bets. This is where learning happens. A team that ships ten small things learns more than a team that ships one large thing, even if the large thing has higher unit quality.

  3. Let Quality rise with feedback. Quality improves fastest when you have real data. Trying to achieve high quality before feedback is guesswork. The loop is: ship at 70%, observe, adjust, repeat. Each cycle moves the quality floor up.

The compounding effect #

This is where the multiplication really pays off. If you run the formula over time (with Continuity kept high, Quantity increasing, and Quality improving with each cycle) the product compounds. Not because any single output is exceptional, but because the feedback loop itself becomes the engine.

That’s not a new idea. It’s what agile retrospectives are for, what continuous delivery is for, what lean startup is for. But it’s easy to lose sight of it when a single hard problem is in front of you and a good discussion feels more productive than a rough prototype.

It usually isn’t.

Related reading: