Finish the Row

I didn't pursue higher education. Instead I spent about four years working farms around the U.S. and overseas, and before that I grew up on one. If there's a single thread tying all of that together, it's fencing. I have dug post holes in more kinds of dirt than I can count, strung more wire than I'd care to add up, and learned — the slow way — what it means to finish something with your hands.

Here's the thing about a fence. At some point it's done. Not "done for now," not "v1," not "done pending review." Done. The wood will gray and a post will eventually rot and want replacing, but the project has an ending, and you get to stand on the far side of that ending, on the porch, with a drink, and look at the thing you made. I felt that a hundred times growing up and on the road, and I never thought twice about it.

Then I went and got a job building web software, and discovered that the porch had been taken away.

Because web software is never done.

We've made a whole religion out of this. We call it perpetual beta — a phrase Tim O'Reilly coined back in 2005 to describe the new way of building for the web, with features "slipstreamed in on a monthly, weekly, or even daily basis," the product developed in the open, forever.^[1] Gmail wore a "beta" label for more than five years, past a hundred million users.^[2] The big shops deploy continuously; Amazon reported a mean time between production deployments of 11.6 seconds on a weekday, and that was back in 2011.^[3] The fence is never finished. There is no porch. You just keep building, and the building is the job, and the job has no end.

For the user, a lot of that is genuinely good — bugs get fixed without anyone driving to a store for a new disc. But the question that nagged at me is the one nobody seems to ask: it might be good for the user (let's grant that, for the sake of argument), but is it good for the person making it?

I think the answer is often no. And I think the whole "never done" premise is a choice we've mistaken for a law of physics. To explain why, I have to take you back to a vegetable farm.

The thirty-foot rows

Somewhere in my traveling years I spent a season — which turned into a few years — on a small farm that grew vegetables, everything done by hand. No tractors. No mechanization. We fed about a hundred families off half an acre, which is staggering if you know anything about growing food, and it was one of the best educations I've ever had.

After a while I started noticing something about the layout. Every vegetable row was the same length — about thirty feet. Thirty, over and over. So I asked the woman who ran the place why. Let's call her Mary.

Mary told me it was deliberate. "Think about the people who have to work that row," she said. "You can't put them in front of a five-hundred-foot row. You can't make somebody stare down the barrel of a thing with no end in sight." A long row, she explained, takes two or three people several days to finish. You spend all day on your knees in the dirt and you have nothing to show for it, no moment where you can stand up and say it's done — and that does something to a person. It burns them out. It drains the will right out of them.

"So we don't do that," she said. "Thirty feet is reasonable. It's calm. It's believable. You can see the finish line before you even start. And when you finish a row, you get a little victory — a small, real hit of satisfaction — and you say, good, that one's done, and you move to the next." A thirty-foot row takes an hour or two. By lunch you might have three or four behind you. And the end of each row is a natural place to stop, turn around, look at what you did, take a breath, and then go again.

I was maybe twenty-something. I filed it away as a nice piece of farm wisdom and didn't think about it for fifteen years.

What Mary knew in her bones

Then I spent years building software, and slowly realized that Mary had been describing, in plain language over a vegetable bed, something psychologists have spent the better part of a century measuring.

Start with the burnout she warned about. The five-hundred-foot row is just boundaryless, never-ending work, and the research on it is grim: when work has no clear endpoint, people ruminate, sleep worse, and run down.^[4] That's the perpetual-beta job. There's no end of the row.

Now the small victories. Teresa Amabile and Steven Kramer analyzed nearly twelve thousand daily diary entries from workers across dozens of project teams, and found that the single biggest driver of a good day at work — more than recognition, more than incentives — was simply making progress in meaningful work.^[5] They called it the progress principle, and the kicker is that the wins don't have to be big. Small, ordinary, finished things are enough. Mary was farming those small victories on purpose. Thirty feet at a time.

Then "you can see the finish line before you even start." There's a name for that, too — the goal-gradient effect, first spotted in lab animals that speed up as they near the food and confirmed in humans buying coffee faster as their loyalty card fills.^[6] Motivation rises as a visible finish line approaches. A five-hundred-foot row never gives you that acceleration, because you can't see the end. Neither does software that's never done. You're always running on a track whose finish keeps receding.

And we are, at a deep level, finishers. Back in 1927 Bluma Zeigarnik noticed that an unfinished task leaves a low hum of tension in the mind that won't quit until the thing is closed out.^[7] Her colleague Maria Ovsiankina found that if you interrupt people mid-task, they'll go back and finish it on their own, unprompted.^[8] An open loop wants to close. Now imagine a job built entirely out of loops that never close.

My favorite piece of this is the IKEA effect — the finding that people prize the wobbly furniture they assembled themselves as if an expert had built it.^[9] Everyone remembers that part. Almost nobody remembers the fine print: the researchers found the affection only appears when the labor succeeds. When people built something and then didn't get to finish it, the feeling evaporated. Completion isn't a bonus on top of effort. Completion is the thing that turns effort into pride.

Finally, the part I now think is the most underrated: those natural stopping points, where you turn around and admire the row. That little ritual is doing three jobs at once, and each one has a literature. You're detaching — Sabine Sonnentag's recovery research shows that mentally stepping away from work is the thing that actually restores you, and that people who can't do it pay in exhaustion.^[10] You're savoring — Fred Bryant and Joseph Veroff gave the specific act of reflecting on something you accomplished a name, "basking," and showed it measurably lifts wellbeing.^[11] And you're reflecting — in one study, call-center trainees who spent their last fifteen minutes a day writing down what they'd learned beat a group that kept working straight through those fifteen minutes by nearly 23%.^[12] Stepping back to look at finished work isn't slacking. It's where the satisfaction and the learning live.

You cannot detach from, bask in, or reflect on a thing that has no end. Perpetual beta quietly deletes all three. Even our memory conspires here — Daniel Kahneman's peak-end rule says we judge an experience largely by its emotional peak and its ending, so work that just trails off forever forfeits the very moment the mind weighs most.^[13]

Mary didn't have any of these citations. She just knew that a person needs to finish a row.

"Never done" is a choice, and people keep proving it

The good news is that the never-ending row was never mandatory. Some of the most beloved software ever written was deliberately, proudly finished.

Donald Knuth froze the feature set of TeX — the typesetting system underneath most of the world's math and science — back in 1990. Since then the only changes are bug fixes, and the version number doesn't climb like normal software. It asymptotically approaches π: 3.14159265, one more digit added with each rare update. Knuth has said that having a system which produces the same output now and decades from now matters more to him than new features, and he's left instructions that the final change, made after his death, will set the version to exactly π, "at which point," he wrote, "all remaining bugs will become features."^[14] That isn't stagnation. That's a craftsman declaring a thing complete and meaning it.

Daniel J. Bernstein wrote the qmail mail server in 1995, offered cash to anyone who could find a security hole, and went about a decade without paying out. His whole philosophy ran the other way from feature-slipstreaming: "Security holes can't show up in features that don't exist."^[15] Or take SQLite, the most widely deployed database on earth — in your phone, probably in your car — whose maintainers publicly commit to "plan as if we will be supporting SQLite until 2050" and promise never to break the file format, so your data outlives you. The Library of Congress recommends it as a preservation format.^[16] Planning to finish, it turns out, forces better engineering, not worse.

And it isn't just the legends. Bare Bones has sold the Mac editor BBEdit since 1993 under the unimprovable slogan "It doesn't suck," and it still ships, still sells once, still respects that you bought it.^[17] Sublime Text is a near-one-person operation that beat venture-funded rivals on sheer speed: ninety-nine dollars, three years of updates, yours forever after.^[18] REAPER, the audio workstation from the guy who made Winamp, costs sixty bucks with free updates through the next whole major version; one reviewer called its pricing "a philosophical statement" against the subscription economy.^[19] Panic in Portland spent twenty-five years making careful, versioned tools and famously turned down Steve Jobs rather than become a feature in someone else's roadmap.^[20] And 37signals keeps old versions of Basecamp running "until the end of the internet,"^[21] shipping work in six-week cycles followed by a real cooldown — instead of an infinite backlog that, as they put it, "gives us a feeling like we're always behind even though we're not."^[22] Thirty-foot rows, basically. Mary would have approved.

None of these people are behind the times. They looked at the perpetual-beta default and simply declined it.

The honest part: you still replace a rotted post

I'd be selling you something cheap if I pretended "finished" had no cost. It does, and the cost is mostly security.

In 2017 the WannaCry ransomware tore through roughly 200,000 computers across about 150 countries and hammered the British NHS — by the National Audit Office's count, disrupting at least a third of England's hospital trusts and hundreds of GP practices, cancelling thousands of appointments. The official verdict was brutally plain: it was "a relatively unsophisticated attack [that] could have been prevented by the NHS following basic IT security best practice."^[23] The machines that fell were the unmaintained ones — unpatched, out of support. Notice the lesson isn't "old software is bad." It's that abandoned software is dangerous. A finished fence and a neglected fence look identical right up until a post gives way.

And this is the thing continuous delivery is genuinely great at. When a hole opens up, a team practicing it can patch and ship in minutes instead of mailing discs. One 2009 study found Chrome's silent auto-updates got 97% of users onto the safe version within three weeks, far ahead of browsers that asked first.^[24] For anything facing the open internet, that responsiveness matters, and I'm not going to wave it away.

So the honest version of my argument isn't "never update." It's finishable software with a maintained floor. Knuth still fixes the rare TeX bug. SQLite is stable and maintained. You design toward an ending, you fight the bloat — Don Norman's old rule is that complexity grows with the square of the feature count, so double the features and you quadruple the mess^[25] — you let the thing be done, and you still walk the fence line each spring and replace the post that rotted. Done is not the same as abandoned. That distinction is the whole ballgame.

Finish the row

Fast-forward fifteen years from that farm. Cue the training montage, smash cut to present day, and I can boil that thirty-foot row down to three words: finish the row. Make something good, complete it, then move to the next one.

Notice that this is not the same as "ship constantly." That distinction is the whole point, and it's easy to blur. Continuous deployment ships endlessly and finishes nothing — it's the five-hundred-foot row with a deploy button bolted on. Velocity isn't the prize. Completion is. A team can push to production forty times a day and still never get the moment where someone stands up, looks at a done thing, and feels it. What you're after isn't a faster treadmill; it's an end to the row.

And finishing in rows isn't only good for the individual on their knees in the dirt — it's good for the whole team's morale, because small victories are also news. People want a steady stream of good news, and a team that finishes a real thing every few weeks generates it naturally. You get to celebrate. You get to announce. You energize the people who built it and you give the people who use it something to be excited about, again and again, instead of one distant mega-release that may never quite arrive. A thirty-foot row, finished, and then the next one.

The perpetual-beta mindset quietly took something from the people who make software, something they never agreed to give up: the porch. The right to stand on the far side of an ending and feel the plain, irreplaceable satisfaction of done. You can get a lot of it back without burning the model down. Cut the work into rows you can actually see the end of. Let yourself call them finished. Build in the natural stopping points where the team turns around, looks at the thing, takes a breath. Kill the backlog that makes everyone feel behind. Finish things, and say so out loud.

Because the deepest reason to work in thirty-foot rows isn't nostalgia. It's that a person who never gets to finish anything slowly forgets they're any good at finishing things. Pride needs an object. It needs a row you can point at, or a fence, or a feature that's live, and say: I made that, and it's done.

The fences I built are still standing. A board's gone gray here and there, and some spring I'll swap a post. But they're done, I knew they were done, and I got my evenings on the porch.

I'd like the people who make our software to get theirs.