In 1975 Fred Brooks told programmers to plan to throw one away, since they were going to anyway. Twenty years later, in the anniversary edition of The Mythical Man-Month, he said the advice was wrong, because it quietly assumed the sequential waterfall model of building software, and what he'd tell people instead was to grow software rather than build it. The correction is worth reading closely. He hadn't been too pessimistic about the first attempt. He'd been too optimistic about the second.

I wrote last time about the distance between a working prototype and something a stranger can download. There's an earlier stretch that gets even less credit, between having the idea and having a version of the idea worth shipping, and almost nobody crosses it in one hop.

Nothing Has Argued With It Yet

An idea in your head feels complete because nothing has pushed back on it. You can describe it start to finish and every part connects, largely because you also got to decide what the parts were. A design document inherits the problem, describing a product nobody has used, written by someone who hasn't used it either.

Games make this easy to see, because the failure mode isn't subtle. A level can be structurally correct, land every beat in the pacing plan, introduce its mechanic exactly where the plan says it should, and still be boring to play, and there is no way to catch that by reading. The same is true of a control scheme that reads fine and feels wrong under a thumb, or a tutorial that explains everything and teaches nothing.

So you build a vertical slice: one thin path through the whole product, playable end to end, mostly to learn what the document couldn't tell you. What comes back is usually a mix of "this part is fine," "this part is worse than I thought," and "this other thing that wasn't in the plan is the actual good bit." The third category is why the slice exists, and it's also why one pass is never enough, since acting on it gives you a new version with a fresh set of surprises in it.

Wide Before Deep

Once something runs, the instinct is to fix it, then fix it again, in a straight line from wherever you started. There's reasonable evidence that spreading out first works better.

In 2010, Steven Dow and colleagues at Stanford published a study in ACM Transactions on Computer-Human Interaction in which novice designers made web banner ads for Ambidextrous, a student-run design journal. One group refined a single ad, taking critique after each version. The other made several different ads in parallel before receiving any feedback at all. The parallel group came out ahead on both measures the study used, expert ratings and click-through data from running the ads live. The two best ads by click-through both came from the parallel group, and the four worst all came from the serial group, two of them drawing no clicks at all.

Nobody in the study was a professional designer and the task was a banner ad, so it's a nudge rather than a law. The mechanism is recognizable, though. Refining a single version commits you to it at the point where you know the least about the problem, and every pass after that is partly a defense of that early commitment. Making three of something tells you which of the three was the real idea, and it's frequently not the one you would have picked off the page.

Some Passes Kill It

Iteration tends to get described as polish, as though the concept were settled and the remaining work were smoothing edges. A decent share of passes end the idea instead.

Stewart Butterfield has now arrived at that ending twice. Ludicorp spent the early 2000s building Game Neverending, a browser MMO, and the part of it people used with any real enthusiasm turned out to be the photo sharing wired into the interface, so the game was abandoned and the photo tool shipped as Flickr in February 2004, assembled largely out of the game's own code. The .gne on Flickr's early URLs was a leftover from Game Neverending. Years later he was running Tiny Speck on another browser game, Glitch, which he shut down in December 2012. What the team carried out of it was the internal chat system they'd built for themselves, which became Slack.

Neither was a case of guessing wrong at the start. Which part of the game mattered only became visible once it existed and people were using it, and both times the decisive pass wasn't a refinement of anything, it was somebody looking at what they had and concluding the premise was gone while the byproduct wasn't. Killing something counts as a result, and it's cheaper now than it has ever been. What stays expensive is the willingness to run that check at all, since a faster build just delivers you to the same question sooner.

Why I Don't Get One-Shotting

All of which is the reason I've never understood the enthusiasm for one-shotting. The pitch is a single prompt, detailed enough, that produces the finished thing on the first try, and I understand why it appeals, because from the inside iteration feels like a penalty for having been vague.

Vagueness isn't the problem. A prompt can only carry what you knew at the time you wrote it, and most of what makes a second version better is the stuff the first version taught you. Getting there in one shot is genuinely useful when the target really is specified in advance, like a migration, a build script, or a component you've written twenty times before. When the open question is whether the thing is any good, the one shot just gets you to the version you can finally react to.

What AI has actually done is take the cost of a pass close to zero, which is an argument for taking more of them. Building a mechanic three different ways used to be a week I'd have had to justify to myself, and now it's an afternoon, so the parallel approach that study points at is finally cheap enough to bother with.

Who decides hasn't moved. Claude will build whichever version I describe, and it builds the third variant of a bad idea as willingly as the first variant of a good one. It'll tell me the code is correct, the state machine is sound, and the frame time is fine. It won't tell me the level is boring, because boring isn't in the code, it's in the person playing it, and somebody still has to sit down and play the thing. That doesn't take taste in any mystical sense. It takes being the person who used it, felt something was off, and could say what.

Which is roughly where Brooks ended up in 1995, in plainer language. Grow, don't build, because the design isn't a thing you finish and then implement. It's what's left over once you've implemented enough of it to see what you actually meant.